Omówienie historii usługi Git

Usługa Git reprezentuje historię w zasadniczo inny sposób niż scentralizowane systemy kontroli wersji (CVCS), takie jak Team Foundation Version Control, 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 systemie Git, mogą mieć wielu rodziców, tworząc historię, która wygląda jak graf zamiast prostej linii. 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ący.

Podstawy historii zatwierdzeń

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

Zatwierdzenie A jest rodzicem zatwierdzenia B, a zatwierdzenie B jest rodzicem zatwierdzenia C. Ta historia wygląda bardzo podobnie do CVCS. Strzałka wskazująca na zatwierdzenie 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 jeden nowy commit, a gałąź główna w repozytorium lokalnym przechodzi na ten commit.

Omówienie historii gałęzi

Teraz nadszedł czas, aby wprowadzić zmianę w kodzie. Często występuje wiele aktywnych gałęzi podczas równoległej pracy nad różnymi funkcjonalnościami. Jest to ostry kontrast do CVCS, gdzie nowe gałęzie są ciężkie i rzadko tworzone. Pierwszym krokiem jest przełączyć się na nową gałąź przy użyciu następującej komendy:

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 zaistniało kilka zmian na gałęzi cool-new-feature w dwóch nowych zatwierdzeniach, E i F.

Zatwierdzenia są osiągalne przez cool-new-feature gałąź, ponieważ zostały do niej zatwierdzone. 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 integrują zatwierdzenia z własnych gałęzi do gałęzi main w tym samym czasie.

Dalsze kroki

Dowiedz się więcej na temat pracy z historią Git w GitHub i Azure Repos lub uproszczaniem historii dzienników Git.