Omówienie historii usługi Git

Usługa Git reprezentuje historię w zasadniczo inny sposób niż scentralizowane systemy kontroli wersji (CVCS), takie jak Kontrola wersji serwera Team Foundation, Perforce lub Subversion. Scentralizowane systemy przechowują oddzielną historię dla każdego pliku w repozytorium. Usługa Git przechowuje historię jako graf migawek całego repozytorium. Te migawki, nazywane zatwierdzeniami w usłudze Git, mogą mieć wiele elementów nadrzędnych , tworząc historię, która wygląda jak graf zamiast prostej. Ta różnica w historii jest niezwykle ważna i jest głównym powodem, dla którego użytkownicy zaznajomieni z CVCS uważają git za mylące.

Podstawy historii zatwierdzeń

Zacznij od prostego przykładu historii: repozytorium z trzema zatwierdzeniami liniowymi.

Zatwierdzenie A jest elementem nadrzędnym zatwierdzenia B, a zatwierdzenie B jest elementem nadrzędnym zatwierdzenia C. Ta historia wygląda bardzo podobnie do CVCS. Strzałka wskazująca zatwierdzenie języka C jest gałęzią. Gałęzie są wskaźnikami do określonych zatwierdzeń, dlatego rozgałęzianie jest tak lekkie i łatwe w usłudze Git.

Kluczową różnicą w usłudze Git w porównaniu z CVCS jest to, że deweloper ma własną pełną kopię repozytorium. Muszą zachować synchronizację repozytorium lokalnego z repozytorium zdalnym, uzyskując najnowsze zatwierdzenia z repozytorium zdalnego. W tym celu ściągają gałąź główną za pomocą następującego polecenia:

git pull origin main

Spowoduje to scalenie wszystkich zmian z gałęzi głównej w repozytorium zdalnym, które domyślnie nazwy origin git. To ściągnięcie przyniosło jedno nowe zatwierdzenie, a gałąź główna w repozytorium lokalnym zostanie przeniesiona do tego zatwierdzenia.

Omówienie historii gałęzi

Teraz nadszedł czas, aby wprowadzić zmianę w kodzie. Często istnieje wiele aktywnych gałęzi podczas równoległego pracy nad różnymi funkcjami. Jest to ostry kontrast do CVCS, gdzie nowe gałęzie są ciężkie i rzadko tworzone. Pierwszym krokiem jest wyewidencjonować nową gałąź przy użyciu następującego polecenia:

git checkout -b cool-new-feature

Jest to skrót łączący dwa polecenia:

• git branch cool-new-feature aby utworzyć gałąź
• git checkout cool-new-feature aby rozpocząć pracę w gałęzi

Dwie gałęzie wskazują teraz to samo zatwierdzenie. Załóżmy, że istnieje kilka zmian w cool-new-feature gałęzi w dwóch nowych zatwierdzeniach, E i F.

Zatwierdzenia są osiągalne przez cool-new-feature gałąź, ponieważ zostały one zatwierdzone do tej gałęzi. Teraz, gdy funkcja jest wykonywana, należy ją scalić z gałęzią główną. W tym celu użyj następującego polecenia:

git merge cool-new-feature main

Struktura grafów historii staje się widoczna w przypadku scalania. Usługa Git tworzy nowe zatwierdzenie po scaleniu gałęzi z inną gałęzią. Jest to zatwierdzenie scalania. Nie ma żadnych zmian uwzględnionych w tym zatwierdzeniu scalania, ponieważ nie wystąpiły konflikty. Jeśli wystąpiły konflikty, zatwierdzenie scalania będzie zawierać zmiany potrzebne do ich rozwiązania.

Historia w świecie rzeczywistym

Oto przykład historii usługi Git, która bardziej przypomina kod w aktywnym tworzeniu w zespole. Istnieją trzy osoby, które scalają zatwierdzenia z własnych gałęzi w main gałęzi w tym samym czasie.

Następne kroki

Dowiedz się więcej na temat pracy z historią usługi Git w usłudze GitHub i usłudze Azure Repos lub uproszczeniem historii dzienników git.