Jak przygotować i przekazać istniejący projekt do usługi GitHub?

Ukończone

W tej lekcji omówimy ważne zagadnienia dotyczące przekazywania projektu do usługi GitHub.

Dlaczego warto przekazywać projekty do usługi GitHub?

Istnieje wiele literatury wychwytujących zalety usługi GitHub i wykracza poza zakres tego modułu, aby przekonać Cię do dołączenia. Jednak w tym module podsumujemy niektóre kluczowe korzyści w kontekście tematów, które należy wziąć pod uwagę podczas planowania przekazywania.

Kontrola wersji

Usługa GitHub korzysta wyłącznie z usługi Git, prawdopodobnie najlepszego systemu kontroli wersji. Jednak usługa Git jest niezwykle zaawansowana i może tworzyć złożone scenariusze pracy z kodem, z którymi może się nie zapoznać twój zespół. Deweloperzy używający systemu Git rutynowo posługują się gałęziami i żądaniami ściągnięcia, dlatego dobre obeznanie z tymi pojęciami to warunek efektywnego korzystania z usługi GitHub. Warto najpierw zapoznać się z przepływem usługi GitHub, aby można było przejść na ziemię.

Przechowywanie kodu w chmurze

Duża ilość kodu projektu jest nadal przechowywana wyłącznie na maszynach deweloperskich. Podczas przekazywania do usługi GitHub przenosisz kod na platformę w chmurze usługi GitHub, gdzie członkowie zespołu mogą łatwo uzyskiwać do niego dostęp z dowolnego miejsca. To dobra okazja do zrewidowania zasad dotyczących przechowywania różnych plików i danych w systemie kontroli wersji. Najlepszym rozwiązaniem jest założenie, że wszystkie elementy, które zobowiązujesz się do usługi GitHub, są potencjalnie zagrożone. Dlatego nie należy uwzględniać poufnych danych, takich jak klucze interfejsu API, hasła lub inne pliki zawierające porównywalne informacje.

Uwaga

Usługa GitHub udostępnia zarówno publiczne, jak i prywatne repozytoria, a także mechanizmy szczegółowej kontroli dostępu do różnych części repozytorium. Dzięki temu możesz kontrolować, kim są widoczne projekty, a także jakie akcje może wykonać dany użytkownik.

Współpraca

Usługa GitHub zapewnia doskonałą obsługę współpracy zespołowej dzięki takim funkcjom, jak problemy, żądania ściągnięcia i przeglądy kodu. Jednak przepływ usługi GitHub może się różnić od praktyk, do których zespół jest obecnie przyzwyczajony. Warto rozważyć, jak zespół może dostosować się do usługi GitHub i określić, czy należy zachować jakiekolwiek istniejące procesy.

Jeśli projekt jest projektem typu open source, który umożliwia współautorom zewnętrznym, nie ma lepszej opcji niż usługa GitHub umożliwiająca maksymalizację tych korzyści.

Przekazywanie do usługi GitHub

Zagadnienia dotyczące planowania

Najważniejsze zagadnienie związane z przekazaniem projektu do usługi GitHub dotyczy tego, czy należy zachować jakieś elementy, których nie obejmuje bieżący stan źródła. Możesz na przykład użyć arkusza kalkulacyjnego lub oprogramowania do zarządzania projektami, aby śledzić błędy, które planujesz naprawić. Obsługa migracji tych elementów różni się w zależności od platformy i jest ogólnie dostępna w projektach społeczności. Ten moduł nie obejmuje migrowania tego typu danych.

Obsługa plików binarnych przechowywanych obecnie w projekcie

Najlepiej jest, gdy w repozytoriach GitHub znajdują się tylko pliki potrzebne do kompilowania projektów. Należy unikać zatwierdzania dużych plików binarnych, takich jak artefakty kompilacji. Pliki binarne, takie jak arkusze kalkulacyjne i prezentacje, można łatwiej śledzić w portalach, które zapewniają prawidłową obsługę tych plików (w tym mechanizmów wersjonowania). Jeśli musisz zapewnić obsługę wersjonowania dużych plików binarnych, możesz użyć rozszerzenia Git LFS (Large File Storage).

Tworzenie ważnych plików Git, takich jak .gitignore

Usługa Git obsługuje .gitignore pliki ułatwiające wymuszanie zasad plików kontroli wersji. Te pliki definiują wzorce wyszukiwania używane do wykluczania plików i folderów ze śledzenia kontroli źródła. Poniższy przykład rekursywnie wyklucza wszystkie foldery o nazwie Bin lub bin oraz ich zawartość ze śledzenia kontroli źródła.

[Bb]in/

Dowiedz się więcej na temat ignorowania plików. Sprawdź również kolekcję plików startowych .gitignore dostępnych dla różnych platform w repozytorium gitignore.

W projektach GitHub często używa się kilku innych plików, które umożliwiają wyjaśnianie różnych zasad użytkownikom i współautorom repozytorium. Nawet w przypadku projektów, które są prywatne, a liczba ich odbiorców jest ograniczona, możliwość jawnego przedstawienia tych zasad może być przydatna. Chociaż żaden z tych plików nie jest wymagany, niektóre z typowych plików są wymienione tutaj.

Plik Purpose
README.md Strona docelowa w katalogu. Strona ta jest renderowana, gdy jej katalog jest wyświetlany w usłudze GitHub.
LICENSE.md Ten plik zawiera licencję, na podstawie której podano kod.
CONTRIBUTING.md Zawiera wskazówki w zakresie współtworzenia projektu (na przykład oczekiwania dotyczące żądań ściągnięcia).
SECURITY.md Objaśnia zasady zabezpieczeń dla projektu. Ten plik zawiera wskazówki dla użytkowników, którzy chcą przesyłać poufny kod związany z zabezpieczeniami lub opinie, które nie powinny być ujawniane publicznie przed rozwiązaniem problemu.

Aby dowiedzieć się więcej, zapoznaj się z artykułem Setting up your project for healthy contributions (Konfigurowanie prawidłowego współtworzenia w projekcie).

Przekazywanie projektu do usługi GitHub

Po przygotowaniu repozytorium do przekazania utwórz repozytorium w usłudze GitHub. W utworzonym repozytorium przejdź na kartę Code (Kod). Ten widok zawiera kilka sposobów przekazywania kodu projektu.

Zrzut ekranu przedstawiający importowanie kodu do repozytorium GitHub.

Zalecamy przekazanie źródła przy użyciu klienta git lub narzędzia przyjaznego dla usługi Git. Możesz też ręcznie przekazać pliki przy użyciu linku umożliwiającego utworzenie nowego pliku. W dłuższej perspektywie prawdopodobnie okaże się, że użycie klienta git jest najlepszym sposobem zarządzania zmianami, gałęziami i nie tylko.