我在 Mastodon 上進(jìn)行了調(diào)查：

你有覺(jué)得哪些 Git 術(shù)語(yǔ)很讓人困惑嗎？我計(jì)劃寫篇博客，來(lái)解讀 Git 中一些奇怪的術(shù)語(yǔ)，如：“分離的 HEAD 狀態(tài)”，“快速前移”，“索引/暫存區(qū)/已暫存”，“比 origin/main 提前 1 個(gè)提交”等等。

我收到了許多有洞見(jiàn)的答案，我在這里試圖概述其中的一部分。下面是這些術(shù)語(yǔ)的列表：

• HEAD 和 “heads”
• “分離的 HEAD 狀態(tài)”
• 在合并或變基時(shí)的 “ours” 和 “theirs”
• “你的分支已經(jīng)與 'origin/main' 同步”
• HEAD^、HEAD~、HEAD^^、HEAD~~、HEAD^2、HEAD~2
• .. 和 ...
• “可以快速前移”
• “引用”、“符號(hào)引用”
• refspecs
• “tree-ish”
• “索引”、“暫存的”、“已緩存的”
• “重置”、“還原”、“恢復(fù)”
• “未跟蹤的文件”、“追蹤遠(yuǎn)程分支”、“跟蹤遠(yuǎn)程分支”
• 檢出
• reflog
• 合并、變基和遴選
• rebase –onto
• 提交
• 更多復(fù)雜的術(shù)語(yǔ)

我已經(jīng)盡力講解了這些術(shù)語(yǔ)，但它們幾乎覆蓋了 Git 的每一個(gè)主要特性，這對(duì)一篇博客而言顯然過(guò)于繁重，所以在某些地方可能會(huì)有一些粗糙。

HEAD 和 “heads”

有些人表示他們對(duì) HEAD 和 refs/heads/main 這些術(shù)語(yǔ)感到困惑，因?yàn)槁?tīng)起來(lái)像是一些復(fù)雜的技術(shù)內(nèi)部實(shí)現(xiàn)。

以下是一個(gè)快速概述：

• “heads” 就是 “分支”。在 Git 內(nèi)部，分支存儲(chǔ)在一個(gè)名為 .git/refs/heads 的目錄中。（從技術(shù)上講，官方 Git 術(shù)語(yǔ)表 中明確表示分支是所有的提交，而 head 只是最近的提交，但這只是同一事物的兩種不同思考方式）
• HEAD 是當(dāng)前的分支，它被存儲(chǔ)在 .git/HEAD 中。

我認(rèn)為，“head 是一個(gè)分支，HEAD 是當(dāng)前的分支” 或許是 Git 中最奇怪的術(shù)語(yǔ)選擇，但已經(jīng)設(shè)定好了，想要更清晰的命名方案已經(jīng)為時(shí)已晚，我們繼續(xù)。

“HEAD 是當(dāng)前的分支” 有一些重要的例外情況，我們將在下面討論。

“分離的 HEAD 狀態(tài)”

你可能已經(jīng)看到過(guò)這條信息：

$ git checkout v0.1
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
[...]

（消息譯文：你處于 “分離 HEAD” 的狀態(tài)。你可以四處看看，進(jìn)行試驗(yàn)性的更改并提交，你可以通過(guò)切換回一個(gè)分支來(lái)丟棄這個(gè)狀態(tài)下做出的任何提交。）

這條信息的實(shí)質(zhì)是：

• 在 Git 中，通常你有一個(gè)已經(jīng)檢出的 “當(dāng)前分支”，例如 main。
• 存放當(dāng)前分支的地方被稱為 HEAD。
• 你做出的任何新提交都會(huì)被添加到你的當(dāng)前分支，如果你運(yùn)行 git merge other_branch，這也會(huì)影響你的當(dāng)前分支。
• 但是，HEAD 不一定必須是一個(gè)分支！它也可以是一個(gè)提交 ID。
• Git 會(huì)稱這種狀態(tài)（HEAD 是提交 ID 而不是分支）為 “分離的 HEAD 狀態(tài)”
• 例如，你可以通過(guò)檢出一個(gè)標(biāo)簽來(lái)進(jìn)入分離的 HEAD 狀態(tài)，因?yàn)闃?biāo)簽不是分支
• 如果你沒(méi)有當(dāng)前分支，一系列事情就斷鏈了：

• git pull 根本就無(wú)法工作（因?yàn)樗娜磕康木褪歉履愕漠?dāng)前分支）
• 除非以特殊方式使用 git push，否則它也無(wú)法工作
• git commit、git merge、git rebase 和 git cherry-pick 仍然可以工作，但它們會(huì)留下“孤兒”提交，這些提交沒(méi)有連接到任何分支，因此找到這些提交會(huì)很困難

• 你可以通過(guò)創(chuàng)建一個(gè)新的分支或切換到一個(gè)現(xiàn)有的分支來(lái)退出分離的 HEAD 狀態(tài)

在合并或變基中的 “ours” 和 “theirs”

遇到合并沖突時(shí)，你可以運(yùn)行 git checkout --ours file.txt 來(lái)選擇 “ours” 版本中的 file.txt。但問(wèn)題是，什么是 “ours”，什么是 “theirs” 呢？

我總感覺(jué)此類術(shù)語(yǔ)混淆不清，也因此從未用過(guò) git checkout --ours，但我還是查找相關(guān)資料試圖理清。

在合并的過(guò)程中，這是如何運(yùn)作的：當(dāng)前分支是 “ours”，你要合并進(jìn)來(lái)的分支是 “theirs”，這樣看來(lái)似乎很合理。

$ git checkout merge-into-ours # 當(dāng)前分支是 “ours”
$ git merge from-theirs # 我們正要合并的分支是 “theirs”

而在變基的過(guò)程中就剛好相反 —— 當(dāng)前分支是 “theirs”，我們正在變基到的目標(biāo)分支是 “ours”，如下：

$ git checkout theirs # 當(dāng)前分支是 “theirs”
$ git rebase ours # 我們正在變基到的目標(biāo)分支是 “ours”

我以為之所以會(huì)如此，因?yàn)樵诓僮鬟^(guò)程中，git rebase main 其實(shí)是將當(dāng)前分支合并到 main （它類似于 git checkout main; git merge current_branch），盡管如此我仍然覺(jué)得此類術(shù)語(yǔ)會(huì)造成混淆。

這個(gè)精巧的小網(wǎng)站 對(duì) “ours” 和 “theirs” 的術(shù)語(yǔ)進(jìn)行了解釋。

人們也提到，VSCode 將 “ours”/“theirs” 稱作 “當(dāng)前的更改”/“收到的更改”，同樣會(huì)引起混淆。

“你的分支已經(jīng)與 origin/main 同步”

此信息貌似很直白 —— 你的 main 分支已經(jīng)與源端同步！

但它實(shí)際上有些誤導(dǎo)?？赡軙?huì)讓你以為這意味著你的 main 分支已經(jīng)是最新的，其實(shí)不然。它真正的含義是 —— 如果你最后一次運(yùn)行 git fetch 或 git pull 是五天前，那么你的 main 分支就是與五天前的所有更改同步。

因此，如果你沒(méi)有意識(shí)到這一點(diǎn)，它對(duì)你的安全感其實(shí)是一種誤導(dǎo)。

我認(rèn)為 Git 理論上可以給出一個(gè)更有用的信息，像是“與五天前上一次獲取的源端 main 是同步的”，因?yàn)樽钚乱淮潍@取的時(shí)間是在 reflog 中記錄的，但它沒(méi)有這么做。

HEAD^、HEAD~、HEAD^^、HEAD~~、HEAD^2、HEAD~2

我早就清楚 HEAD^ 代表前一次提交，但我很長(zhǎng)一段時(shí)間都困惑于 HEAD~ 和 HEAD^ 之間的區(qū)別。

我查詢資料，得到了如下的對(duì)應(yīng)關(guān)系：

• HEAD^ 和 HEAD~ 是同一件事情（指向前 1 個(gè)提交）
• HEAD^^^、HEAD~~~ 和 HEAD~3 是同一件事情（指向前 3 個(gè)提交）
• HEAD^3 指向提交的第三個(gè)父提交，它與 HEAD~3 是不同的

這看起來(lái)有些奇怪，為什么 HEAD~ 和 HEAD^ 是同一個(gè)概念？以及，“第三個(gè)父提交”是什么？難道就是父提交的父提交的父提交？（劇透：并非如此）讓我們一起深入探討一下！

大部分提交只有一個(gè)父提交。但是合并提交有多個(gè)父提交 - 因?yàn)樗鼈兒喜⒘藘蓚€(gè)或更多的提交。在 Git 中，HEAD^ 意味著 “HEAD 提交的父提交”。但是如果 HEAD 是一個(gè)合并提交，那 HEAD^ 又代表怎么回事呢？

答案是，HEAD^ 指向的是合并提交的第一個(gè)父提交，HEAD^2 是第二個(gè)父提交，HEAD^3 是第三個(gè)父提交，等等。

但我猜他們也需要一個(gè)方式來(lái)表示“前三個(gè)提交”，所以 HEAD^3 是當(dāng)前提交的第三個(gè)父提交（如果當(dāng)前提交是一個(gè)合并提交，可能會(huì)有很多父提交），而 HEAD~3 是父提交的父提交的父提交。

我想，從我們之前對(duì)合并提交 “ours”/“theirs” 的討論來(lái)看，HEAD^ 是 “ours”，HEAD^2 是 “theirs”。

.. 和 ...

這是兩個(gè)命令：

• git log main..test
• git log main...test

我從沒(méi)用過(guò) .. 和 ... 這兩個(gè)命令，所以我得查一下 man git-range-diff。我的理解是比如這樣一個(gè)情況：

A - B main
  \
    C - D test

• main..test 對(duì)應(yīng)的是提交 C 和 D
• test..main 對(duì)應(yīng)的是提交 B
• main...test 對(duì)應(yīng)的是提交 B，C，和 D

更有挑戰(zhàn)的是，git diff 顯然也支持 .. 和 ...，但它們?cè)?nbsp;git log 中的意思完全不同？我的理解如下：

• git log test..main 顯示在 main 而不在 test 的更改，但是 git log test...main 則會(huì)顯示 兩邊
• git diff test..main 顯示 test 變動(dòng) 和 main 變動(dòng)（它比較 B 和 D），而 git diff test...main 會(huì)比較 A 和 D（它只會(huì)給你顯示一邊的差異）。

有關(guān)這個(gè)的更多討論可以參考 這篇博客文章。

“可以快速前移”

在 git status 中，我們會(huì)經(jīng)常遇到如下的信息：

$ git status
On branch main
Your branch is behind 'origin/main' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

（消息譯文：你現(xiàn)在處于 main 分支上。你的分支比 origin/main 分支落后了 2 個(gè)提交，可以進(jìn)行快速前進(jìn)。 (使用 git pull 命令可以更新你的本地分支)）

但“快速前移” 到底是何意？本質(zhì)上，它在告訴我們這兩個(gè)分支基本如下圖所示（最新的提交在右側(cè)）：

main:        A - B - C
origin/main: A - B - C - D - E

或者，從另一個(gè)角度理解就是：

A - B - C - D - E (origin/main)
        |
        main

這里，origin/main 僅僅多出了 2 個(gè) main 不存在的提交，因此我們可以輕松地讓 main 更新至最新 —— 我們所需要做的就是添加上那 2 個(gè)提交。事實(shí)上，這幾乎不可能出錯(cuò) —— 不存在合并沖突?？焖偾斑M(jìn)式合并是個(gè)非常棒的事情！這是合并兩個(gè)分支最簡(jiǎn)單的方式。

運(yùn)行完 git pull 之后，你會(huì)得到如下?tīng)顟B(tài)：

main:        A - B - C - D - E
origin/main: A - B - C - D - E

下面這個(gè)例子展示了一種不能快速前進(jìn)的狀態(tài)。

A - B - C - X  (main)
        |
        - - D - E  (origin/main)

此時(shí)，main 分支上有一個(gè) origin/main 分支上無(wú)的提交（X），所以無(wú)法執(zhí)行快速前移。在此種情況，git status 就會(huì)如此顯示：

$ git status
Your branch and 'origin/main' have diverged,
and have 1 and 2 different commits each, respectively.

（你的分支和 origin/main 分支已經(jīng)產(chǎn)生了分歧，其中各有 1 個(gè)和 2 個(gè)不同的提交。）

“引用”、“符號(hào)引用”

在使用 Git 時(shí)，“引用” 一詞可能會(huì)使人混淆。實(shí)際上，Git 中被稱為 “引用” 的實(shí)例至少有三種：

• 分支和標(biāo)簽，例如 main 和 v0.2
• HEAD，代表當(dāng)前活躍的分支
• 諸如 HEAD^^^ 這樣的表達(dá)式，Git 會(huì)將其解析成一個(gè)提交 ID。確切說(shuō)，這可能并非 “引用”，我想 Git 將其稱作 “版本參數(shù)”，但我個(gè)人并未使用過(guò)這個(gè)術(shù)語(yǔ)。

個(gè)人而言，“符號(hào)引用” 這個(gè)術(shù)語(yǔ)頗為奇特，因?yàn)槲矣X(jué)得我只使用過(guò) HEAD（即當(dāng)前分支）作為符號(hào)引用。而 HEAD 在 Git 中占據(jù)核心位置，多數(shù) Git 核心命令的行為都基于 HEAD 的值，因此我不太確定將其泛化成一個(gè)概念的實(shí)際意義。

refspecs

在 .git/config 配置 Git 遠(yuǎn)程倉(cāng)庫(kù)時(shí)，你可能會(huì)看到這樣的代碼 +refs/heads/main:refs/remotes/origin/main 。

[remote "origin"]
    url = git@github.com:jvns/pandas-cookbook
    fetch = +refs/heads/main:refs/remotes/origin/main

我對(duì)這段代碼的含義并不十分清楚，我通常只是在使用 git clone 或 git remote add 配置遠(yuǎn)程倉(cāng)庫(kù)時(shí)采用默認(rèn)配置，并沒(méi)有動(dòng)機(jī)去深究或改變。

“tree-ish”

在 git checkout 的手冊(cè)頁(yè)中，我們可以看到：

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...

那么這里的 tree-ish 是什么意思呢？其實(shí)當(dāng)你執(zhí)行 git checkout THING . 時(shí)，THING 可以是以下的任一種：

• 一個(gè)提交 ID（如 182cd3f）
• 對(duì)一個(gè)提交 ID 的引用（如 main 或 HEAD^^ 或 v0.3.2）
• 一個(gè)位于提交內(nèi)的子目錄（如 main:./docs）
• 可能就這些？

對(duì)我個(gè)人來(lái)說(shuō)，“提交內(nèi)的目錄”這個(gè)功能我從未使用過(guò)，從我的視角看，tree-ish 可以解讀為“提交或?qū)μ峤坏囊谩薄?/p>

“索引”、“暫存”、“緩存”

這些術(shù)語(yǔ)都指向的是同一樣?xùn)|西（文件 .git/index，當(dāng)你執(zhí)行 git add 時(shí)，你的變動(dòng)會(huì)在這里被暫存）：

• git diff --cached
• git rm --cached
• git diff --staged
• 文件 .git/index

盡管它們都是指向同一個(gè)文件，但在實(shí)際使用中，這些術(shù)語(yǔ)的應(yīng)用方式有所不同：

• 很顯然，--index 和 --cached 并不總是表示同一種意思。我自己從未使用 --index，所以具體細(xì)節(jié)我就不展開(kāi)討論了，但是你可以在 Junio Hamano（Git 的主管維護(hù)者）的博客文章 中找到詳細(xì)解釋。
• “索引” 會(huì)包含未跟蹤的文件（我猜可能是對(duì)性能的考慮），但你通常不會(huì)把未跟蹤的文件考慮在“暫存區(qū)”內(nèi)。

“重置”、“還原”、“恢復(fù)”

許多人提到，“重置reset”、“還原revert” 和 “恢復(fù)restore” 這三個(gè)詞非常相似，易使人混淆。

我認(rèn)為這部分的困惑來(lái)自以下原因：

• git reset --hard 和 git restore . 單獨(dú)使用時(shí)，基本上達(dá)到的效果是一樣的。然而，git reset --hard COMMIT 和 git restore --source COMMIT . 相互之間是完全不同的。
• 相應(yīng)的手冊(cè)頁(yè)沒(méi)有給出特別有幫助的描述：

• git reset: “重置當(dāng)前 HEAD 到指定的狀態(tài)”
• git revert: “還原某些現(xiàn)有的提交”
• git restore: “恢復(fù)工作樹(shù)文件”

雖然這些簡(jiǎn)短的描述為你詳細(xì)說(shuō)明了哪個(gè)名詞受到了影響（“當(dāng)前 HEAD”，“某些提交”，“工作樹(shù)文件”），但它們都預(yù)設(shè)了你已經(jīng)知道在這種語(yǔ)境中，“重置”、“還原”和“恢復(fù)”的準(zhǔn)確含義。

以下是對(duì)它們各自功能的簡(jiǎn)要說(shuō)明：

• 重置 —— git revert COMMIT: 在你當(dāng)前的分支上，創(chuàng)建一個(gè)新的提交，該提交是 COMMIT 的“反向”操作（如果 COMMIT 添加了 3 行，那么新的提交就會(huì)刪除這 3 行）。
• 還原 —— git reset --hard COMMIT: 強(qiáng)行將當(dāng)前分支回退到 COMMIT 所在的狀態(tài)，抹去自 COMMIT 以來(lái)的所有更改。這是一個(gè)高風(fēng)險(xiǎn)的操作。
• 恢復(fù) —— git restore --source=COMMIT PATH: 將 PATH 中的所有文件回退到 COMMIT 當(dāng)時(shí)的狀態(tài)，而不擾亂其他文件或提交歷史。

“未跟蹤的文件”、“遠(yuǎn)程跟蹤分支”、“跟蹤遠(yuǎn)程分支”

在 Git 中，“跟蹤” 這個(gè)詞以三種相關(guān)但不同的方式使用：

• “未跟蹤的文件Untracked files”：在 git status 命令的輸出中可以看到。這里，“未跟蹤” 意味著這些文件不受 Git 管理，不會(huì)被計(jì)入提交。
• “遠(yuǎn)程跟蹤分支remote tracking branch” 例如 origin/main。此處的“遠(yuǎn)程跟蹤分支”是一個(gè)本地引用，旨在記住上次執(zhí)行 git pull 或 git fetch 時(shí)，遠(yuǎn)程 origin 上 main 分支的狀態(tài)。
• 我們經(jīng)?？吹筋愃?“分支 foo 被設(shè)置為跟蹤 origin 上的遠(yuǎn)程分支 bar ”這樣的提示。

即使“未跟蹤的文件”和“遠(yuǎn)程跟蹤分支”都用到了“跟蹤”這個(gè)詞，但是它們所在的上下文完全不同，所以沒(méi)有太多混淆。但是，對(duì)于以下兩種方式的“跟蹤”使用，我覺(jué)得可能會(huì)產(chǎn)生些許困擾：

• main 是一個(gè)跟蹤遠(yuǎn)程的分支
• origin/main 是一個(gè)遠(yuǎn)程跟蹤分支

然而，在 Git 中，“跟蹤遠(yuǎn)程的分支” 和 “遠(yuǎn)程跟蹤分支” 是不同的事物，理解它們之間的區(qū)別非常關(guān)鍵！下面是對(duì)這兩者區(qū)別的一個(gè)簡(jiǎn)單概述：

• main 是一個(gè)分支。你可以在它上面做提交，進(jìn)行合并等操作。在 .git/config 中，它通常被配置為 “追蹤” 遠(yuǎn)程的 main 分支，這樣你就可以用 git pull 和 git push 來(lái)同步和上傳更改。
• origin/main 則并不是一個(gè)分支，而是一個(gè)“遠(yuǎn)程跟蹤分支”，這并不是一種真正的分支（這有些抱歉）。你不能在此基礎(chǔ)上做提交。只有通過(guò)運(yùn)行 git pull 或 git fetch 獲取遠(yuǎn)程 main 的最新?tīng)顟B(tài)，才能更新它。

我以前沒(méi)有深入思考過(guò)這種模糊的地方，但我認(rèn)為很容易看出為什么它會(huì)讓人感到困惑。

簽出

簽出做了兩個(gè)完全無(wú)關(guān)的事情：

• git checkout BRANCH 用于切換分支
• git checkout file.txt 用于撤銷對(duì) file.txt 的未暫存修改

這是眾所周知的混淆點(diǎn)，因此 Git 實(shí)際上已經(jīng)將這兩個(gè)功能分離到了 git switch 和 git restore（盡管你還是可以使用 checkout，就像我一樣，在不愿丟棄 15 年對(duì) git checkout 肌肉記憶的情況下）。

再者，即使用了 15 年，我仍然記不住 git checkout main file.txt 用于從 main 分支恢復(fù) file.txt 版本的命令參數(shù)。

我覺(jué)得有時(shí)你可能需要在 checkout 命令后面加上--，幫助區(qū)分哪個(gè)參數(shù)是分支名，哪個(gè)是路徑，但我并未這么使用過(guò)，也不確定何時(shí)需要這樣做。

參考日志（reflog）

有很多人把 reflog 讀作 re-flog，而不是 ref-log。由于本文已經(jīng)足夠長(zhǎng)，我這里不會(huì)深入討論參考日志，但值得注意的是：

• 在 Git 中，“參考” 是一個(gè)泛指分支、標(biāo)簽和 HEAD 的術(shù)語(yǔ)
• 參考日志（“reflog”）則為你提供了一個(gè)參考?xì)v次記錄的歷史追蹤
• 它是從一些極端困境中拯救出來(lái)的利器，比如說(shuō)你不小心刪除了重要的分支
• 我覺(jué)得參考日志是 Git 用戶界面中最難懂的部分，我總是試圖避免使用它。

合并 vs 變基 vs 遴選

有許多人提及他們常常對(duì)于合并和變基的區(qū)別感到迷惑，并且不理解變基中的“基base”指的是什么。

我會(huì)在這里盡量簡(jiǎn)要的進(jìn)行描述，但是這些一句話的解釋最終可能并不那么明了，因?yàn)槊總€(gè)人使用合并和變基創(chuàng)建工作流程時(shí)的方式差別挺大，要真正理解合并和變基，你必須理解工作流程。此外，有圖示會(huì)更好理解。不過(guò)這個(gè)話題可能需要一篇獨(dú)立的博客文章來(lái)完整討論，所以我不打算深入這個(gè)問(wèn)題。

• 合并會(huì)創(chuàng)建一個(gè)新的提交，用來(lái)融合兩個(gè)分支
• 變基則會(huì)逐個(gè)地把當(dāng)前分支上的提交復(fù)制到目標(biāo)分支
• 遴選跟變基類似，但是語(yǔ)法完全不同（一個(gè)顯著的差異是變基是從當(dāng)前分支復(fù)制提交，而遴選則會(huì)把提交復(fù)制到當(dāng)前分支）

rebase --onto

在 git rebase 中，存在一個(gè)被稱為 --onto 的選項(xiàng)。這一直讓我感到困惑，因?yàn)?nbsp;git rebase main 的核心功能就是將當(dāng)前分支變基到 main 運(yùn)行上。那么，額外的 --onto 參數(shù)又是怎么回事呢？

我進(jìn)行了一番查找，--onto 顯然解決了一個(gè)我?guī)缀鯖](méi)有或者說(shuō)從未遇到過(guò)的問(wèn)題，但我還是會(huì)記錄下我對(duì)它的理解。

A - B - C (main)
      \
      D - E - F - G (mybranch)
          |
          otherbranch

設(shè)想一下，出于某種原因，我只想把提交 F 和 G 變基到 main 上。我相信這應(yīng)該是某些 Git 工作流中會(huì)經(jīng)常遇到的場(chǎng)景。

顯然，你可以運(yùn)行 git rebase --onto main otherbranch mybranch 來(lái)完成這個(gè)操作。對(duì)我來(lái)說(shuō)，在這個(gè)語(yǔ)法中記住 3 個(gè)不同的分支名順序似乎是不可能的（三個(gè)分支名，對(duì)我來(lái)說(shuō)實(shí)在太多了），但由于我從很多人那里聽(tīng)說(shuō)過(guò)，我想它一定有它的用途。

提交

有人提到他們對(duì) Git 中的提交作為一詞雙義（既作為動(dòng)詞也作為名詞）的用法感到困惑。

例如：

• 動(dòng)詞：“別忘了經(jīng)常提交”
• 名詞：“main 分支上最新的提交”

我覺(jué)得大多數(shù)人應(yīng)該能很快適應(yīng)這個(gè)雙關(guān)的用法，但是在 SQL 數(shù)據(jù)庫(kù)中的“提交”用法與 Git 是有所不同，我認(rèn)為在 SQL 數(shù)據(jù)庫(kù)中，“提交”只是作為一個(gè)動(dòng)詞（你使用 COMMIT 來(lái)結(jié)束一個(gè)事務(wù)），并不作為名詞。

此外，在 Git 中，你可以從以下三個(gè)不同的角度去考慮一個(gè) Git 提交：

1. 表示當(dāng)前每個(gè)文件狀態(tài)的快照
2. 與父提交的差異
3. 記錄所有先前提交的歷史

這些理解都是不錯(cuò)的：不同的命令在所有的這些情況下都會(huì)使用提交。例如，git show 將提交視為一個(gè)差異，git log 把提交看作是歷史，git restore 則將提交理解為一個(gè)快照。

然而，Git 的術(shù)語(yǔ)并無(wú)太多助于你理解一個(gè)給定的命令正在如何使用提交。

更多令人困惑的術(shù)語(yǔ)

以下是更多讓人覺(jué)得混淆的術(shù)語(yǔ)。我對(duì)許多這些術(shù)語(yǔ)的意思并不十分清楚。

我自己也不是很理解的東西：

• git pickaxe （也許這是 git log -S 和 git log -G，它們用于搜索以前提交的差異？）
• 子模塊（我知道的全部就是它們并不以我想要的方向工作）
• Git 稀疏檢出中的 “cone mode” （沒(méi)有任何關(guān)于這個(gè)的概念，但有人提到過(guò)）

人們提及覺(jué)得混淆，但我在這篇已經(jīng) 3000 字的文章中略過(guò)的東西：

• blob、tree
• “合并” 的方向
• “origin”、“upstream”，“downstream”
• push 和 pull 并不是對(duì)立面
• fetch 和 pull 的關(guān)系（pull = fetch + merge）
• git porcelain
• 子樹(shù)
• 工作樹(shù)
• 暫存
• “master” 或者 “main” （聽(tīng)起來(lái)它在 Git 內(nèi)部有特殊含義，但其實(shí)并沒(méi)有）
• 何時(shí)需要使用 origin main（如 git push origin main）vs origin/main

人們提及感到困惑的 Github 術(shù)語(yǔ)：

• “拉取請(qǐng)求pull request” （與 Gitlab 中的 “合并請(qǐng)求merge request” 相比，人們似乎認(rèn)為后者更清晰）
• “壓扁并合并” 和 “變基并合并” 的作用 （在昨天我從未聽(tīng)說(shuō)過(guò) git merge --squash，我一直以為 “壓扁并合并” 是 Github 的特殊功能）

確實(shí)是 “每個(gè) Git 術(shù)語(yǔ)”

我驚訝地發(fā)現(xiàn)，幾乎 Git 的每個(gè)其他核心特性都被至少一人提及為某種方式中的困惑。我對(duì)聽(tīng)到更多我錯(cuò)過(guò)的混淆的 Git 術(shù)語(yǔ)的例子也有興趣。

關(guān)于這個(gè)，有另一篇很棒的 2012 年的文章叫做《最困惑的 Git 術(shù)語(yǔ)》。它更多的討論的是 Git 術(shù)語(yǔ)與 CVS 和 Subversion 術(shù)語(yǔ)的關(guān)聯(lián)。

如果我要選出我覺(jué)得最令人困惑的 3 個(gè) Git 術(shù)語(yǔ)，我現(xiàn)在會(huì)選：

• head 是一個(gè)分支，HEAD 是當(dāng)前分支
• “遠(yuǎn)程跟蹤分支” 和 “跟蹤遠(yuǎn)程的分支” 是不同的事物
• “索引”、“暫存的”、“已緩存的” 全部指的同一件事

就這樣了！

在寫這些的過(guò)程中，我學(xué)到了不少東西。我了解到了一些新的關(guān)于Git的事實(shí)，但更重要的是，現(xiàn)在我對(duì)于別人說(shuō)Git的所有功能和特性都引起困惑有了更深的理解。

許多問(wèn)題我之前根本沒(méi)考慮過(guò)，比如我從來(lái)沒(méi)有意識(shí)到，在討論分支時(shí)，“跟蹤”這個(gè)詞的用法是多么地特別。

另外，盡管我已經(jīng)盡力做到準(zhǔn)確無(wú)誤，但由于我涉獵到了一些我從未深入探討過(guò)的Git的角落，所以可能還是出現(xiàn)了一些錯(cuò)誤。