瞭解 Git 歷程記錄

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Git 會將歷程記錄儲存為整個存放庫的快照集圖表，稱為認可。 每個認可也包含一或多個先前認可的指標。 認可可以有多個父代，建立看起來像圖形而非直線的歷程記錄。 這段歷史差異非常重要，而且是用戶發現 Git 混淆的主要原因。

注意

如果您在您知道的 Git 歷程記錄中找不到變更，請深入瞭解 Git 歷程記錄簡化如何在 Git 中簡化我的變更：查看 Git 的歷程記錄簡化。

認可歷程記錄基本概念

從簡單的歷程記錄範例開始：具有3個線性認可的存放庫。

認可 A 是認可 B 的父代，而認可 B 是認可 C 的父代。此歷程記錄看起來與 CVCS 非常類似。 指向認可 C 的箭號是分支。 其名稱 main 為 ，因為這是 Git 存放庫中 mainline 分支的預設名稱。 分支是特定認可的指標，這就是為什麼分支在 Git 中是如此羽量且容易。

Git 與 CVCS 相比的主要差異在於我有自己的存放庫完整複本。 我需要從遠端存放庫取得最新的認可，讓本機存放庫與遠端存放庫保持同步。 若要這樣做，我會使用下列命令提取 main 分支：

git pull origin main

這會將所有認可從 main 遠端存放庫的分支（預設呼叫 origin ） main 複製到本機存放庫的分支。 提取作業複製了一個新的認可，而 main 本機存放庫中的分支現在指向這個新的認可。

瞭解分支歷程記錄

現在我想變更我的程序代碼。 通常有多個作用中分支，您可以在其中平行處理不同的功能。 這與 CVCS 形成鮮明對比，其中新分支繁重且很少建立。 第一個步驟是使用下列命令簽出至新的分支：

git checkout -b cool-new-feature

這是結合兩個命令的快捷方式： git branch cool-new-feature 建立分支， git checkout cool-new-feature 後面接著開始在分支中工作。

兩個分支現在指向相同的認可。 我會在兩個新的認可 E 和 F 中，在 cool-new-feature 分支上進行一些變更。

自從我在該分支中建立認可之後，我的認可可透過 cool-new-feature 分支來連線。 我已完成功能，並想要將其合併至 main。 若要這樣做，我將使用下列命令：

git merge cool-feature main

當合併時，記錄的圖表結構就會變成可見。 當我將分支合併到另一個分支時，Git 會建立新的認可。 這是合併認可。 由於我沒有衝突，因此此合併認可中並未包含任何變更。 如果我發生衝突，合併認可會包含解決這些衝突所需的變更。

真實世界的歷史

以下是 Git 歷程記錄的範例，更類似於小組作用中開發中的程式碼。 有三個人會同時將自己的分支認可合併到主要分支。

既然您已瞭解分支和合併如何建立圖形的形狀，這不應該太可怕！