Git 以與集中式版本控制系統 （CVCS） （例如 Team Foundation 版本控制、Perforce 或 Subversion） 完全不同的方式來表示歷史記錄。 集中式系統會儲存儲存庫中每個檔案的個別歷程記錄。 Git 將歷史記錄儲存為整個儲存庫的快照圖表。 這些快照在 Git 中稱為 提交 ，可以有多個父級，從而創建看起來像圖表而不是直線的歷史記錄。 這種歷史差異非常重要，也是熟悉 CVCS 的使用者發現 Git 令人困惑的主要原因。
提交歷史的基本概念
從一個簡單的歷史記錄範例開始：具有三個線性提交的儲存庫。
認可 A 是認可 B 的父代，而認可 B 是認可 C 的父代。此歷程記錄看起來與 CVCS 非常類似。 指向提交 C 的箭號是分支。 分支是指向特定提交的指標，這就是為什麼在 Git 中分支是如此輕量且容易。
與 CVCS 相比，Git 的一個主要區別是開發人員擁有自己的存放庫的完整副本。 他們需要從遠端儲存庫取得最新的提交，以便保持本機儲存庫與遠端儲存庫的同步。 為此，他們使用以下命令拉取主要分支：
git pull origin main
這會合併遠端儲存庫中主要分支的所有變更，預設情況下 Git 會命名 origin 該分支。 此拉取帶來了一個新的提交，而本機存放庫中的主分支移至該提交。
瞭解分支歷程
現在是時候更改代碼了。 在並行處理不同的功能時，通常會有多個作用中分支。 這與 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 分支可以存取這些提交，因為它們是提交到該分支的。
現在該功能已完成，需要將其合併到主分支中。 若要這樣做，請使用下列命令：
git merge cool-new-feature main
當進行合併時，歷史的圖表結構會顯現出來。 當分支合併到另一個分支時，Git 會建立新的提交。 這是合併提交。 由於沒有衝突，因此此合併不包含任何更改。 如果發生衝突，合併認可會包含解決衝突所需的變更。
真實世界的歷史
以下是 Git 歷程記錄的範例，更類似於小組中主動開發的程式碼。
大約同時，有三個人將自己分支的提交合併到分支 main 中。
後續步驟
深入瞭解如何在 GitHub 和 Azure Repos 中使用 Git 歷程記錄或 Git 記錄歷程記錄簡化。