Git 提交是差異、快照還是歷史記錄？

作者：Julia Evans 2024-01-22 10:01:41

大家好！我一直在慢慢摸索如何解釋 Git 中的各個核心理念（提交、分支、遠程、暫存區），而提交這個概念卻出奇地棘手。

要明白 Git 提交是如何實現的對我來說相當簡單（這些都是確定的！我可以直接查看！），但是要弄清楚別人是怎么看待提交的卻相當困難。所以，就像我最近一直在做的那樣，我在 Mastodon 上問了一些問題。

大家是怎么看待 Git 提交的？

我進行了一個非常不科學的調查，詢問大家是怎么看待 Git 提交的：是快照、差異，還是所有之前提交的列表？（當然，把它看作這三者都是合理的，但我很好奇人們的主要

結果是：

51% 差異
42% 快照
4% 所有之前的提交的歷史記錄
3% “其他”

我很驚訝差異和快照兩個選項的比例如此接近。人們還提出了一些有趣但相互矛盾的觀點，比如 “在我看來，提交是一個差異，但我認為它實際上是以快照的形式實現的” 和 “在我看來，提交是一個快照，但我認為它實際上是以差異的形式實現的”。關于提交的實際實現方式，我們稍后再詳談。

在我們進一步討論之前：我們的說 “一個差異” 或 “一個快照” 都是什么意思？

什么是差異？

我說的“差異”可能相當明顯：差異就是你在運行 git show COMMIT_ID 時得到的東西。例如，這是一個 rbspy 項目中的拼寫錯誤修復：

diff --git a/src/ui/summary.rs b/src/ui/summary.rs
index 5c4ff9c..3ce9b3b 100644
--- a/src/ui/summary.rs
+++ b/src/ui/summary.rs
@@ -160,7 +160,7 @@ mod tests {
  ";
          let mut buf: Vec<u8> = Vec::new();
-        stats.write(&mut buf).expect("Callgrind write failed");
+        stats.write(&mut buf).expect("summary write failed");
          let actual = String::from_utf8(buf).expect("summary output not utf8");
          assert_eq!(actual, expected, "Unexpected summary output");
      }

你可以在 GitHub 上看到它： https://github.com/rbspy/rbspy/commit/24ad81d2439f9e63dd91cc1126ca1bb5d3a4da5b

什么是快照？

我說的 “快照” 是指 “當你運行 git checkout COMMIT_ID 時得到的所有文件”。

Git 通常將提交的文件列表稱為 “樹”（如“目錄樹”），你可以在 GitHub 上看到上述提交的所有文件：

https://github.com/rbspy/rbspy/tree/24ad81d2439f9e63dd91cc1126ca1bb5d3a4da5b（它是 /tree/ 而不是 /commit/）

“Git 是如何實現的”真的是正確的解釋方式嗎？

我最常聽到的關于學習 Git 的建議大概是 “只要學會 Git 在內部是如何表示事物的，一切都會變得清晰明了”。我顯然非常喜歡這種觀點（如果你花了一些時間閱讀這個博客，你就會知道我喜歡

但是作為一個學習 Git 的方法，它并沒有我希望的那么成功！通常我會興奮地開始解釋 “好的，所以 Git 提交是一個快照，它有一個指向它的父提交的指針，然后一個分支是一個指向提交的指針，然后……”，但是我試圖幫助的人會告訴我，他們并沒有真正發現這個解釋有多有用，他們仍然不明白。所以我一直在考慮其他方案。

但是讓我們還是先談談內部實現吧。

Git 是如何在內部表示提交的 —— 快照

在內部，Git 將提交表示為快照（它存儲每個文件當前版本的 “樹”）。我在在一個 Git 倉庫中，你的文件在哪里？中寫過這個，但下面是一個非常快速的內部格式概述。

這是一個提交的表示方式：

$ git cat-file -p 24ad81d2439f9e63dd91cc1126ca1bb5d3a4da5b
tree e197a79bef523842c91ee06fa19a51446975ec35
parent 26707359cdf0c2db66eb1216bf7ff00eac782f65
author Adam Jensen <adam@acj.sh> 1672104452 -0500
committer Adam Jensen <adam@acj.sh> 1672104890 -0500
Fix typo in expectation message

以及，當我們查看這個樹對象時，我們會看到這個提交中倉庫根目錄下每個文件/子目錄的列表：

$ git cat-file -p e197a79bef523842c91ee06fa19a51446975ec35
040000 tree 2fcc102acd27df8f24ddc3867b6756ac554b33ef    .cargo
040000 tree 7714769e97c483edb052ea14e7500735c04713eb    .github
100644 blob ebb410eb8266a8d6fbde8a9ffaf5db54a5fc979a    .gitignore
100644 blob fa1edfb73ce93054fe32d4eb35a5c4bee68c5bf5    ARCHITECTURE.md
100644 blob 9c1883ee31f4fa8b6546a7226754cfc84ada5726    CODE_OF_CONDUCT.md
100644 blob 9fac1017cb65883554f821914fac3fb713008a34    CONTRIBUTORS.md
100644 blob b009175dbcbc186fb8066344c0e899c3104f43e5    Cargo.lock
100644 blob 94b87cd2940697288e4f18530c5933f3110b405b    Cargo.toml

這意味著檢出一個 Git 提交總是很快的：對 Git 來說，檢出昨天的提交和檢出 100 萬個提交之前的提交一樣容易。Git 永遠不需要重新應用 10000 個差異來確定當前狀態，因為提交根本就不是以差異的形式存儲的。

快照使用 packfile 進行壓縮

我剛剛提到了 Git 提交是一個快照，但是，當有人說 “在我看來，提交是一個快照，但我認為它在實現上是一個差異” 時，這其實也是對的！Git 提交并不是以你可能習慣的差異的形式表示的（它們不是以與上一個提交的差異的形式存儲在磁盤上的），但基本的直覺是，如果你要對一個 10,000 行的文件編輯 500 次，那么存儲 500 份文件的效率會很低。

Git 有一個將文件以差異的形式存儲的方法。這被稱為 “packfile”，Git 會定期進行垃圾回收，將你的數據壓縮成 packfile 以節省磁盤空間。當你 git clone 一個倉庫時，Git 也會壓縮數據。

這里，我沒有足夠的篇幅來完整地解釋 packfile 是如何工作的（Aditya Mukerjee 的《解壓 Git packfile》是我最喜歡的解釋它們是如何工作的文章）。不過，我可以在這里簡單總結一下我對 deltas 工作原理的理解，以及它們與 diff 的區別：

對象存儲為 “原始文件” 和一個 “變化量delta” 的引用
變化量是一系列例如 “讀取第 0 到 100 字節，然后插入字節 ‘hello there’，然后讀取第 120 到 200 字節” 的指令。它從原始文件中拼湊出新的文本。所以沒有 “刪除” 的概念，只有復制和添加。
我認為變化量的層次較少：我不知道如何檢查 Git 究竟要經過多少層變化量才能得到一個給定的對象，但我的印象是通常不會很多。可能少于 10 層？不過，我很想知道如何才能真正查出來。
原始文件不一定來自上一個提交，它可以是任何東西。也許它甚至可以來自一個更晚的提交？我不確定。
沒有一個 “正確的” 算法來計算變化量，Git 只是有一些近似的啟發式算法

當你查看差異時，實際上發生了一些奇怪的事情

當我們運行 git show SOME_COMMIT 來查看某個提交的差異時，實際上發生的事情有點反直覺。我的理解是：

Git 會在 packfile 中查找并應用變化量來重建該提交和其父提交的樹。
Git 會對兩個目錄樹（當前提交的目錄樹和父提交的目錄樹）進行差異比較。通常這很快，因為幾乎所有的文件都是完全一樣的，所以 git 只需比較相同文件的哈希值就可以了，幾乎所有時候都不用做什么。
最后 Git 會展示差異

所以，Git 會將變化量轉換為快照，然后計算差異。它感覺有點奇怪，因為它從一個類似差異的東西開始，最終得到另一個類似差異的東西，但是變化量和差異實際上是完全不同的，所以這是說得通的。

也就是說，我認為 Git 將提交存儲為快照，而 packfile 只是一個實現細節，目的是節省磁盤空間并加快克隆速度。我其實從來沒必要知道 packfile 是如何工作的，但它確實能幫助我理解 Git 是如何在不占用太多磁盤空間的情況下將提交快照化的。

一個 “錯誤的” Git 理解：提交是差異

我認為一個相當常見的，對 Git 的 “錯誤” 的理解是：

提交是以基于上一個提交的差異的形式存儲的（加上指向父提交的指針和作者和消息）。
要獲取提交的當前狀態，Git 需要從頭開始重新應用所有之前的提交。

這個理解當然是錯誤的（在現實中，提交是以快照的形式存儲的，差異是從這些快照計算出來的），但是對我來說它似乎非常有用而且有意義！在考慮合并提交時會有一點奇怪，但是或許我們可以說這只是基于合并提交的第一個父提交的差異。

我認為這個錯誤的理解有的時候非常有用，而且對于日常 Git 使用來說它似乎并沒有什么問題。我真的很喜歡它將我們最常使用的東西（差異）作為最基本的元素——它對我來說非常直觀。

我也一直在思考一些其他有用但 “錯誤” 的 Git 理解，比如：

提交信息可以被編輯（實際上不能，你只是復制了一個相同的提交然后給了它一個新的信息，舊的提交仍然存在）
提交可以被移動到一個不同的基礎上（類似地，它們是被復制了）

我認為有一系列非常有意義的、 “錯誤” 的對 Git 的理解，它們在很大程度上都受到 Git 用戶界面的支持，并且在大多數情況下都不會產生什么問題。但是當你想要撤銷一個更改或者出現問題時，它可能會變得混亂。

將提交視為差異的一些優勢

就算我知道在 Git 中提交是快照，我可能大部分時間也都將它們視為差異，因為：

大多時候我都在關注我正在做的更改 —— 如果我只是改變了一行代碼，顯然我主要是在考慮那一行代碼而不是整個代碼庫的當前狀態
點擊 GitHub 上的 Git 提交或者使用 git show 時，你會看到差異，所以這只是我習慣看到的東西
我經常使用變基，它就是關于重新應用差異的

將提交視為快照的一些優勢

但是我有時也會將提交視為快照，因為：

Git 經常對文件的移動感到困惑：有時我移動了一個文件并編輯了它，Git 無法識別它是否被移動過，而是顯示為 “刪除了 old.py，添加了 new.py”。這是因為 Git 只存儲快照，所以當它顯示 “移動 old.py -> new.py” 時，只是猜測，因為 old.py 和 new.py 的內容相似。
這種方式更容易理解 git checkout COMMIT_ID 在做什么（重新應用 10000 個提交的想法讓我感到很有壓力）
合并提交在我看來更像是快照，因為合并的提交實際上可以是任何東西（它只是一個新的快照！）。它幫助我理解為什么在解決合并沖突時可以進行任意更改，以及為什么在解決沖突時要小心。

其他一些關于提交的理解

Mastodon 的一些回復中還提到了：

有關提交的 “額外的” 帶外信息，比如電子郵件、GitHub 拉取請求或者你和同事的對話
將“差異”視為一個“之前的狀態 + 之后的狀態”
以及，當然，很多人根據情況的不同以不同的方式看待提交

人們在談論提交時使用的其他一些詞可能不那么含糊：

“修訂”（似乎更像是快照）
“補丁”（看起來更像是差異）

就到這里吧！

我很難了解人們對 Git 有哪些不同的理解。尤其棘手的是，盡管 “錯誤” 的理解往往非常有用，但人們卻非常熱衷于警惕 “錯誤” 的心智模式，所以人們不愿意分享他們 “錯誤” 的想法，生怕有什么 Git 解釋者會站出來向他們解釋為什么他們是錯的。（這些 Git 解釋者通常是出于善意的，但是無論如何它都會產生一種負面影響）

但是我學到了很多！我仍然不完全清楚該如何談論提交，但是我們最終會弄清楚的。

感謝 Marco Rogers、Marie Flanagan 以及 Mastodon 上的所有人和我討論 Git 提交。

責任編輯：龐桂玉來源： Linux中國

Git 提交快照