Omówienie historii usługi Git

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Usługa Git przechowuje historię jako graf migawek — nazywanych zatwierdzeniami — całego repozytorium. Każde zatwierdzenie zawiera również wskaźnik do co najmniej jednego poprzedniego zatwierdzenia. Zatwierdzenia mogą zawierać 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 uważają git za mylące.

Uwaga

Jeśli nie możesz znaleźć zmiany w historii usługi Git, którą znasz, dowiedz się więcej o tym, jak uproszczenie historii usługi Git działa w usłudze Git straciło moje zmiany: Zapoznaj się z uproszczeniem historii usługi Git.

Podstawy historii zatwierdzeń

Zacznij od prostego przykładu historii: repozytorium z 3 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ą. Nazwa jest nazwana main , ponieważ jest to domyślna nazwa gałęzi głównej w repozytorium Git. 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 mam własną pełną kopię repozytorium. Chcę zachować synchronizację repozytorium lokalnego z repozytorium zdalnym, uzyskując najnowsze zatwierdzenia z repozytorium zdalnego. W tym celu pobierzę gałąź główną za pomocą następującego polecenia:

git pull origin main

Spowoduje to skopiowanie wszystkich zatwierdzeń z main gałęzi repozytorium zdalnego (wywoływanego origin domyślnie) do main gałęzi repozytorium lokalnego. Operacja ściągania skopiowała jedno nowe zatwierdzenie, a main gałąź w repozytorium lokalnym wskazuje teraz to nowe zatwierdzenie.

Omówienie historii gałęzi

Teraz chcę wprowadzić zmianę w kodzie. Często istnieje wiele aktywnych gałęzi, w których pracujesz równolegle z 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łąź, po której git checkout cool-new-feature następuje rozpoczęcie pracy w gałęzi.

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

Moje zatwierdzenia są osiągalne przez cool-new-feature gałąź, ponieważ zostały one wykonane w tej gałęzi. Wykonano moją funkcję i chcę ją scalić z elementem main. W tym celu użyję następującego polecenia:

git merge cool-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 zawartych w tym zatwierdzeniu scalania, ponieważ nie miałem konfliktów. Gdybym miał konflikty, zatwierdzenie scalania obejmowało zmiany potrzebne do rozwiązania tych konfliktów.

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 gałęzi głównej w tym samym czasie.

Teraz, gdy już wiesz, jak gałęzie i scalają kształt grafu, nie powinno to być zbyt przerażające!