Eksplorowanie kontroli wersji przy użyciu usługi Git

  • 5 minut

Istnieją różne typy systemów kontroli wersji (VCS), ale ogólnie można je skategoryzować jako scentralizowane i rozproszone. W ostatnich latach (częściowo ze względu na rosnącą popularność metodyki DevOps) ta ostatnia kategoria zyskała znaczną popularność, a usługa Git stała się de facto standardem we współczesnym tworzeniu oprogramowania. Ten konkretny vcS byłby najbardziej odpowiednim wyborem dla organizacji w naszym przykładowym scenariuszu, szczególnie biorąc pod uwagę zamiar użycia usługi GitHub jako platformy docelowej na potrzeby przejścia metodyki DevOps. W tej lekcji zapoznasz się z użyciem usługi Git jako kontroli wersji.

Zrzut ekranu przedstawiający tabelę porównującą scentralizowane i rozproszone korzyści z systemów kontroli wersji.

Scentralizowana i rozproszona kontrola wersji

Zarówno scentralizowane systemy kontroli wersji (CVCS) i rozproszone systemy kontroli wersji (DVCS) oferują możliwość zarządzania zmianami i śledzenia zmian w projektach tworzenia oprogramowania. Podstawowe różnice między nimi są związane ze sposobem implementowania repozytoriów i współpracy. W szczególności:

  • Lokalizacja repozytorium: W scentralizowanych systemach istnieje pojedyncze, scentralizowane wystąpienie repozytorium zawierające pełną historię projektu. W systemach rozproszonych każdy członek zespołu zazwyczaj ma jedną, w pełni funkcjonalną lokalną kopię całego repozytorium, potencjalnie obejmującą pełną historię wersji.
  • łączność sieciowa: W scentralizowanych systemach dostęp do scentralizowanego wystąpienia repozytorium jest konieczny do wykonywania wielu czynności, w tym aktualizacji i pobierania historii. W systemach rozproszonych wszystkie działania można wykonywać względem lokalnej kopii repozytorium.
  • model współpracy: w scentralizowanych systemach deweloperzy pobierają pliki ze scentralizowanego wystąpienia repozytorium, łącząc się z nią przez sieć, przed wprowadzeniem modyfikacji i zatwierdzeniem zmian. Zapobiega to dokonywaniu zmian w wyewidencjonowanych plikach przez inne osoby. W systemach rozproszonych deweloperzy wprowadzają i zatwierdzają zmiany w lokalnej kopii repozytorium, które w pewnym momencie są synchronizowane z innymi kopiami.
  • Model rozgałęziania i scalania: W scentralizowanych systemach, rozgałęzianie i scalanie zwykle wymaga koordynacji z innymi. W systemach rozproszonych gałęzie można tworzyć niezależnie w kopiach lokalnych i scalać później.

Warto zauważyć, że chociaż model rozproszony nie opiera się na centralnym repozytorium (w tradycyjnym sensie), często implementuje jedną kopię repozytorium, która jest hostowana przez usługi, takie jak GitHub, GitLab lub Bitbucket. To wystąpienie stanowi centralny punkt współpracy i synchronizacji.

Zrzut ekranu przedstawiający repozytoria scentralizowanych i rozproszonych systemów kontroli wersji oraz współpracę.

Terminologia dotycząca usługi Git

Aby stać się biegłym w pracy z usługą Git, ważne jest zapoznanie się z jego terminologią. Niektóre koncepcje są unikatowe dla usługi Git, wyróżniając je od innych DVCS. Najbardziej podstawowe terminy usługi Git obejmują:

  • Drzewo robocze: struktura katalogów zawierająca wszystkie pliki projektu.
  • Repozytorium (często nazywane repozytorium): katalog znajdujący się na najwyższym poziomie drzewa roboczego, hostuje wszystkie pliki projektu wraz z historią wersji tych plików.
  • Klon: akcja tworzenia kopii repozytorium zdalnego na komputerze lokalnym w celu pracy nad projektem, do którego masz dostęp.
  • Rozwidlenie: akcja tworzenia kopii repozytorium zdalnego hostowanej w usłudze GitHub w celu pracy nad projektem, do którego nie masz dostępu. Rozgałęzienie jest zwykle używane, jeśli zamierzasz przyczynić się do projektu innej osoby lub utworzyć własną wersję takiego projektu. Chociaż nie masz dostępu do zapisu do oryginalnego repozytorium, możesz w pełni zarządzać swoim forkiem.
  • commit: migawka zawartości wprowadzonych w plikach w repozytorium w danym momencie czasu. Do rejestrowania i zapisywania zmian używa się zatwierdzeń.
  • Obszar przejściowy to lokalizacja pośrednia (która nie jest częścią repozytorium), gdzie zmiany w plikach w drzewie roboczym są przygotowywane przed ich zatwierdzeniem. Dzięki niej deweloperzy mogą wybierać zmiany, które zamierzają zatwierdzić.
  • Branch: nazwana seria połączonych commitów. Mówiąc prosto, gałąź reprezentuje odrębną wersję projektu. Umożliwia to pracę nad różnymi częściami projektu jednocześnie bez wpływu na jego wersję główną. Najnowszy komit w gałęzi nazywany jest head. Gałąź domyślna wygenerowana automatycznie podczas inicjowania repozytorium jest nazywana główną lub główną.
  • Scalanie: proces łączenia zmian z jednej gałęzi (lub zatwierdzenia) do innej. Integruje to zmiany z jednej gałęzi z inną.
  • Obiekt: jeden z czterech typów jednostek dostępnych w repozytorium. Jednostki te obejmują bloby reprezentujące poszczególne pliki, drzewo robocze reprezentujące drzewo robocze, zatwierdzenie reprezentujące określoną wersję drzewa roboczego oraz tag, który jest etykietą przypisaną do pojedynczego zatwierdzenia.
  • Funkcja skrótu: automatycznie wygenerowany, unikatowy, stałej długości identyfikator, reprezentujący zawartość obiektu. Za każdym razem, gdy ten obiekt ulegnie zmianie, jego skrót również się zmienia. Dzięki temu usługa Git może określić, która zawartość w repozytorium została zaktualizowana.
  • Zdalne: odniesienie do innego repozytorium (oprócz lokalnego), zazwyczaj wskazujące wersję repozytorium hostowanego przez usługę. Służy to jako wartość domyślna dla operacji wypychania i ściągania.
  • Pobieranie: akcja pobierająca zmiany z zdalnego repozytorium i scala je z bieżącą gałęzią.
  • push: akcja, która wysyła lokalne zatwierdzenia do repozytorium zdalnego, aktualizując je zmianami wprowadzonymi lokalnie.
  • pobieranie: czynność pobierania zmian z repozytorium zdalnego bez automatycznego ich scalania. Umożliwia to ich przegląd przed zastosowaniem scalania.
  • Pull request: funkcja na platformach hostingu opartych na systemie Git (na przykład GitHub), która umożliwia deweloperom proponowanie zmian i wnioskowanie o scalenie ich z gałęzią docelową.

Git ma również obszerny zestaw poleceń, które zapewniają możliwość pełnego prowadzenia kontroli wersji i zarządzania nią za pomocą powłoki poleceń, takiej jak powłoka Bash w systemie Linux lub wiersz polecenia systemu Windows. Alternatywnie można zarządzać usługą Git za pomocą aplikacji klasycznych, takich jak GitHub Desktop. Platformy hostingu oparte na usłudze Git udostępniają interfejs internetowy, który ułatwia interakcję z repozytoriami po stronie usługi.

Git vs GitHub

Zgodnie z wcześniejszym opisem usługa Git to wieloplatformowa wersja DVCS typu open source, która ułatwia współpracę przy użyciu repozytoriów lokalnych, które mogą być synchronizowane z repozytoriami zdalnymi. GitHub to oparta na chmurze usługa, która udostępnia platformę hostingową dla repozytoriów Git. Rozszerza ona zakres możliwości usługi Git, włączając obsługę następujących elementów:

  • Repozytoria zdalne: ułatwianie interakcji między rozproszonymi zespołami.
  • narzędzia do współpracy: dostarczanie takich funkcji jak zgłoszenia problemów, dyskusje, żądania ściągnięcia zmian, powiadomienia, etykiety, akcje, forki, witryny typu wiki i projekty.
  • Interfejs internetowy: minimalizacja konieczności używania poleceń usługi Git
  • Ochrona gałęzi: wymuszanie warunków, które muszą zostać spełnione przed przeprowadzeniem połączenia (na przykład ukończone przeglądy pull requestów).