git checkout：“他們的”和“我們的”的詳細含義

Question

git checkout 文檔說：

--ours --theirs從索引中檢查路徑時，請檢查第 2 階段（我們的）或第 3 階段（他們的）未合並的路徑。

在合並、rebase 和cherry-pick 期間“stage #2”和“stage #3”是什么意思？ 有沒有辦法在運行命令之前查詢這些“階段”以確保它會檢索到正確的版本？

Answer 1

這些在gitrevisions文檔中都有記錄（雖然我認為不是很清楚）：

一個冒號，可選地后跟一個階段編號（0 到 3）和一個冒號，后跟一個路徑，在給定路徑的索引中命名一個 blob 對象。 缺少的階段編號（以及它后面的冒號）將命名為階段 0 條目。 在合並期間，階段 1 是共同祖先，階段 2 是目標分支的版本（通常是當前分支），階段 3 是正在合並的分支的版本。

對於這些，您需要添加有關git rebase和git cherry-pick工作的知識。

正常的櫻桃選擇是明確定義的：“我們的”是HEAD版本，即您曾經（現在仍然）所在的分支，而“他們的”是您正在積極選擇的提交。 當你摘櫻桃單個提交，這一切都非常明顯：第一階段＃1是假想，共同始祖犯^，1個階段＃2從當前分支的末端的版本，和舞台＃3你的版本”重新采摘櫻桃。

如果您挑選一系列提交，這仍然是正確的，它只是迭代正確。 例如，假設您正在挑選三個提交。 Git 一次只做三個。 在第一次挑選時，階段#2 是你的分支的尖端，階段 #3 是第一個提交的版本被挑選出來。 一旦那個提交cherry-pick完成，git就會進行一個新的提交，推進你的分支的尖端。 然后，在第二次cherry-pick 期間，階段#2 是你的分支的尖端，這是你的第一個cherry-pick 的提交，階段#3 是被選擇的第二次提交的版本。 對於最終提交，這再次重復。 每次，第 3 階段都是“他們的”版本。

然而，Rebase 有點棘手。 在內部，它首先讓您進入一個新的匿名分支（“分離的 HEAD”）。 然后它運行git cherry-pick從原始分支中選擇每個提交。 這意味着“我們的”是分離的 HEAD 版本，而“他們的”是來自原始分支的版本。 就像cherry-pick一樣，對於每個要選擇的提交都會迭代重復（在交互式rebase的情況下，您可以在其中編輯pick行）。 一旦 rebase 完成，git 只是簡單地將分支標簽打亂，這樣你剛剛創建的新匿名分支就是你的代碼。

簡而言之，您可以將 rebase 視為“反轉我們/他們的設置”——但這有點誇張。 更准確地說，第 2 階段是您的新代碼，而第 3 階段是您的舊代碼。

---

階段#1是定義的合並基礎。 對於真正的合並，這是最好的共同祖先提交，但cherry-pick 強制將其傳遞給被cherry-picked 的提交的父級。 （Revert 以類似的方式工作，除了被“復制”的提交是父提交，而“合並基礎”是被還原的提交。）

Answer 2

合並的Git 文檔（以及其他一些地方）解釋了一個索引文件最多記錄三個版本或階段：

對於沖突路徑，索引文件最多記錄三個版本：階段 1 存儲來自共同祖先的版本，階段 2 來自 HEAD，階段 3 來自 MERGE_HEAD（您可以使用 git ls-files -u 檢查階段）。 工作樹文件包含“合並”程序的結果； 即具有熟悉的沖突標記 <<< === >>> 的 3 路合並結果。

下圖顯示了典型 Git 合並中的三個階段：

Common Ancestor -> C1  --- C2         <- MERGE_HEAD (Stage 3)
(Stage 1)             \
                        --- C3 --- C4 <- HEAD (Stage 2)

這假設HEAD為C4的分支正在合並回以C2結尾的分支。

正如文檔所述，您實際上可以通過鍵入以下內容來查看階段：

git ls-files -u