瞭解 Git 歷程記錄

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

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

備註

如果您無法在自己知道的 Git 歷史記錄中找到變更，請進一步了解 Git 歷史記錄簡化的運作方式，參閱 Git 遺失了我的變更：了解 Git 的歷史記錄簡化。

提交歷史的基本概念

從一個簡單的歷史範例開始：一個有三個線性提交的存放庫。

在三個提交紀錄

認可 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 開始在分支中工作。

兩個分支現在指向相同的認可。 我會在 cool-new-feature 分支上，透過兩個新的提交 E 和 F 做一些變更。

我的提交在 cool-new-feature 分支中被建立，因此該分支可以存取這些提交。 我已完成功能，並想要將其合併至 main。 若要這樣做，我將使用下列命令：

git merge cool-feature main

合併後的

當進行合併時，歷史的圖表結構會顯現出來。 當我將分支合併到另一個分支時，Git 會建立一個新的提交。 這是合併提交。 由於我沒有遇到衝突，因此在這次合併提交中沒有包含任何變更。 如果我發生衝突，合併認可會包含解決這些衝突所需的變更。

真實世界的歷史

以下是 Git 歷程記錄的範例，更類似於團隊正在開發中的程式碼。 有三個人在差不多同一時間將他們自己的分支合併到主要分支。

git graph主控台記錄

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