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

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

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

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

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

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

結(jié)果是：

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

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

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

什么是差異？

我說的“差異”可能相當(dāng)明顯：差異就是你在運(yùn)行 git show COMMIT_ID 時(shí)得到的東西。例如，這是一個(gè) rbspy 項(xiàng)目中的拼寫錯(cuò)誤修復(fù)：

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

什么是快照？

我說的 “快照” 是指 “當(dāng)你運(yùn)行 git checkout COMMIT_ID 時(shí)得到的所有文件”。

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

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

“Git 是如何實(shí)現(xiàn)的”真的是正確的解釋方式嗎？

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

但是作為一個(gè)學(xué)習(xí) Git 的方法，它并沒有我希望的那么成功！通常我會興奮地開始解釋 “好的，所以 Git 提交是一個(gè)快照，它有一個(gè)指向它的父提交的指針，然后一個(gè)分支是一個(gè)指向提交的指針，然后……”，但是我試圖幫助的人會告訴我，他們并沒有真正發(fā)現(xiàn)這個(gè)解釋有多有用，他們?nèi)匀徊幻靼住Ｋ晕乙恢痹诳紤]其他方案。

但是讓我們還是先談?wù)剝?nèi)部實(shí)現(xiàn)吧。

Git 是如何在內(nèi)部表示提交的 —— 快照

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

這是一個(gè)提交的表示方式：

$ 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

以及，當(dāng)我們查看這個(gè)樹對象時(shí)，我們會看到這個(gè)提交中倉庫根目錄下每個(gè)文件/子目錄的列表：

$ 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

這意味著檢出一個(gè) Git 提交總是很快的：對 Git 來說，檢出昨天的提交和檢出 100 萬個(gè)提交之前的提交一樣容易。Git 永遠(yuǎn)不需要重新應(yīng)用 10000 個(gè)差異來確定當(dāng)前狀態(tài)，因?yàn)樘峤桓揪筒皇且圆町惖男问酱鎯Φ摹?/p>

快照使用 packfile 進(jìn)行壓縮

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

Git 有一個(gè)將文件以差異的形式存儲的方法。這被稱為 “packfile”，Git 會定期進(jìn)行垃圾回收，將你的數(shù)據(jù)壓縮成 packfile 以節(jié)省磁盤空間。當(dāng)你 git clone 一個(gè)倉庫時(shí)，Git 也會壓縮數(shù)據(jù)。

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

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

當(dāng)你查看差異時(shí)，實(shí)際上發(fā)生了一些奇怪的事情

當(dāng)我們運(yùn)行 git show SOME_COMMIT 來查看某個(gè)提交的差異時(shí)，實(shí)際上發(fā)生的事情有點(diǎn)反直覺。我的理解是：

Git 會在 packfile 中查找并應(yīng)用變化量來重建該提交和其父提交的樹。
Git 會對兩個(gè)目錄樹（當(dāng)前提交的目錄樹和父提交的目錄樹）進(jìn)行差異比較。通常這很快，因?yàn)閹缀跛械奈募际峭耆粯拥模?git 只需比較相同文件的哈希值就可以了，幾乎所有時(shí)候都不用做什么。
最后 Git 會展示差異

所以，Git 會將變化量轉(zhuǎn)換為快照，然后計(jì)算差異。它感覺有點(diǎn)奇怪，因?yàn)樗鼜囊粋€(gè)類似差異的東西開始，最終得到另一個(gè)類似差異的東西，但是變化量和差異實(shí)際上是完全不同的，所以這是說得通的。

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

一個(gè) “錯(cuò)誤的” Git 理解：提交是差異

我認(rèn)為一個(gè)相當(dāng)常見的，對 Git 的 “錯(cuò)誤” 的理解是：

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

這個(gè)理解當(dāng)然是錯(cuò)誤的（在現(xiàn)實(shí)中，提交是以快照的形式存儲的，差異是從這些快照計(jì)算出來的），但是對我來說它似乎非常有用而且有意義！在考慮合并提交時(shí)會有一點(diǎn)奇怪，但是或許我們可以說這只是基于合并提交的第一個(gè)父提交的差異。

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

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

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

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

將提交視為差異的一些優(yōu)勢

就算我知道在 Git 中提交是快照，我可能大部分時(shí)間也都將它們視為差異，因?yàn)椋?/p>

大多時(shí)候我都在關(guān)注我正在做的更改 —— 如果我只是改變了一行代碼，顯然我主要是在考慮那一行代碼而不是整個(gè)代碼庫的當(dāng)前狀態(tài)
點(diǎn)擊 GitHub 上的 Git 提交或者使用 git show 時(shí)，你會看到差異，所以這只是我習(xí)慣看到的東西
我經(jīng)常使用變基，它就是關(guān)于重新應(yīng)用差異的

將提交視為快照的一些優(yōu)勢

但是我有時(shí)也會將提交視為快照，因?yàn)椋?/p>

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

其他一些關(guān)于提交的理解

Mastodon 的一些回復(fù)中還提到了：

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

人們在談?wù)撎峤粫r(shí)使用的其他一些詞可能不那么含糊：

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

就到這里吧！

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

但是我學(xué)到了很多！我仍然不完全清楚該如何談?wù)撎峤唬俏覀冏罱K會弄清楚的。

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

責(zé)任編輯：龐桂玉來源： Linux中國