--我们的 --他们的 从索引中检查路径时，请检查阶段 #2 (ours) 或 #3 (theirs) 以获取未合并的路径。
在合并、变基和cherry-pick期间，“stage #2”和“stage #3”是什么意思？有没有办法在运行命令之前查询这些“阶段”以确保它会检索到正确的版本？
【问题讨论】：
标签： git version-control merge git-branch branching-and-merging
这些都记录在the gitrevisions documentation：
一个冒号（可选地后跟一个阶段号（0 到 3）和一个冒号，后跟一个路径，在给定路径的索引中命名一个 blob 对象。缺少的阶段编号（及其后面的冒号）命名阶段 0 条目。在合并期间，阶段 1 是共同祖先，阶段 2 是目标分支的版本（通常是当前分支），阶段 3 是正在合并的分支的版本。
然后，您需要添加有关 git rebase 和 git cherry-pick 工作原理的知识。
正常的樱桃采摘是明确定义的：“我们的”是HEAD 版本，即您曾经（现在仍然是）所在的分支，而“他们的”是您正在积极采摘的提交。当您选择单个提交时，一切都很明显：阶段 #1 是所谓的共同祖先提交，1 阶段 #2 是当前分支尖端的版本，阶段#3 是您选择的版本。
如果您选择一系列提交，这仍然是正确的，它只是迭代地正确。例如，假设您正在挑选三个提交。 Git 一次只做三个。在第一次cherry-pick 期间，stage #2 是您分支的尖端，stage #3 是从第一次提交开始的版本。一旦提交 cherry-pick 完成，git 会进行新的提交，从而推进分支的尖端。然后，在第二次 cherry-pick 期间，stage #2 是您分支的尖端，这是您第一次 cherry-pick 所做的提交，stage #3 是第二次被挑选的提交的版本。对于最终提交，这再次重复。每次，第 3 阶段都是“他们的”版本。
然而，Rebase 有点棘手。在内部，它首先让您进入一个新的匿名分支（“分离的 HEAD”）。然后它运行git cherry-pick 以从您的原始分支中选择每个提交。这意味着“我们的”是分离的 HEAD 版本，而“他们的”是原始分支的版本。就像cherry-pick 一样，对于要选择的每个提交，这都会迭代重复（字面意思是在交互式rebase 的情况下，您编辑pick 行）。一旦 rebase 完成，git 会简单地打乱分支标签，这样你刚刚创建的新匿名分支就是你的代码。
简而言之，您可以将 rebase 视为“反转我们/他们的设置”——但这是夸大其词。更准确的说法可能是第 2 阶段是您的新融合代码，而第 3 阶段是您的旧代码。
Stage #1 是定义的合并基础。对于真正的合并，这是最好的共同祖先提交，但cherry-pick 将其强制提交给正在挑选的提交的父级。 （Revert 以类似的方式工作，只是被“复制”的提交是父提交，而“合并基”是被恢复的提交。）
【讨论】：
Git documentation for merge（以及其他一些地方）解释说索引文件最多记录三个版本或阶段：
对于冲突的路径，索引文件最多记录三个版本：阶段 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
【讨论】：