Vysvětlení historie Gitu

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Git ukládá historii jako graf snímků – označovaných jako potvrzení – celého úložiště. Každé potvrzení obsahuje také ukazatel na jedno nebo více předchozích potvrzení. Potvrzení můžou mít více nadřazených objektů a vytvořit historii, která místo přímky vypadá jako graf. Tento rozdíl v historii je neuvěřitelně důležitý a je hlavním důvodem, proč uživatelé najdou Git matoucí.

Poznámka:

Pokud nemůžete najít změnu v historii Gitu, kterou víte, že jste udělali, přečtěte si další informace o tom, jak zjednodušení historie Gitu funguje na Gitu, ztratilo moje změny: Podívejte se na zjednodušení historie Gitu.

Základy historie potvrzení

Začněte jednoduchým příkladem historie: úložiště se 3 lineárními potvrzeními.

Commit A je nadřazeným objektem potvrzení B a potvrzení B je nadřazeným objektem potvrzení C. Tato historie vypadá velmi podobně jako CVCS. Šipka ukazující na potvrzení C je větev. Jmenuje se main , protože se jedná o výchozí název hlavní větve v úložišti Git. Větve jsou ukazatele na konkrétní potvrzení, což je důvod, proč je větvení v Gitu tak jednoduché a jednoduché.

Klíčovým rozdílem v Gitu oproti CVCS je, že mám vlastní úplnou kopii úložiště. Potřebuji zachovat místní úložiště synchronizované se vzdáleným úložištěm získáním nejnovějších potvrzení ze vzdáleného úložiště. Uděláte to tak, že vytáhnem hlavní větev pomocí následujícího příkazu:

git pull origin main

Tato kopie ("načte") všechna potvrzení z main větve vzdáleného úložiště (ve výchozím nastavení volána origin ) do main větve místního úložiště. Operace přijetí změn zkopírovala jedno nové potvrzení a main větev v místním úložišti teď ukazuje na toto nové potvrzení.

Principy historie větví

Teď chci změnit kód. Je běžné mít několik aktivních větví, ve kterých pracujete na různých funkcích paralelně. Je to ve velkém kontrastu s CVCS, kde jsou nové větve těžké a zřídka vytvářené. Prvním krokem je rezervovat novou větev pomocí následujícího příkazu:

git checkout -b cool-new-feature

Toto je zkratka, která kombinuje dva příkazy: git branch cool-new-feature vytvoření větve následované git checkout cool-new-feature zahájením práce ve větvi.

Dvě větve teď ukazují na stejné potvrzení. Udělám několik změn ve cool-new-feature větvi ve dvou nových potvrzeních, E a F.

Moje potvrzení jsou dosažitelná cool-new-feature větví, protože jsem je v této větvi udělal. Mám hotovou funkci a chci ji sloučit do main. K tomu použijem následující příkaz:

git merge cool-feature main

Struktura grafu historie se zobrazí, když dojde ke sloučení. Git vytvoří nové potvrzení při sloučení větve do jiné větve. Toto je potvrzení sloučení. V tomto potvrzení sloučení nejsou zahrnuty žádné změny, protože nemám konflikty. Kdybych měl konflikty, potvrzení sloučení by zahrnovalo změny potřebné k vyřešení těchto konfliktů.

Historie v reálném světě

Tady je příklad historie Gitu, která se více podobá kódu v aktivním vývoji v týmu. Existují tři lidé, kteří sloučí potvrzení ze svých vlastních větví do hlavní větve přibližně ve stejnou dobu.

Teď, když rozumíte tomu, jak větve a slučují tvar grafu, by to nemělo být příliš děsivé!