在git的结帐文档说:
--ours --theirs 当从索引检查出路径,检查阶段#2(我们)或#3(他们的)用于未合并的路径.
在合并,rebase和cherry-pick期间,"阶段#2"和"阶段#3"的含义是什么?有没有办法在运行命令之前查询这些"阶段"以确保它将检索正确的版本?
这些都记录(虽然不是全部清楚,我认为)中的gitrevisions
文件:
冒号,可选地后跟一个阶段号(0到3)和一个冒号,后跟一个路径,在给定路径的索引中命名一个blob对象.缺少的阶段编号(以及其后面的冒号)命名阶段0条目.在合并期间,阶段1是共同的祖先,阶段2是目标分支的版本(通常是当前分支),阶段3是正在合并的分支的版本.
然后,您需要添加有关如何git rebase
和git cherry-pick
工作的知识.
正常的樱桃采摘是明确定义的:"我们的"是HEAD
版本,即您(并且仍在)的分支,而"他们的"是您正在积极挑选的提交.当你挑选一个提交时,一切都很明显:第一阶段是共同的祖先,阶段#2是你当前分支的尖端版本,阶段#3是你挑选的版本.
如果你挑选一系列提交,这仍然是正确的,它只是迭代的真实.比如说,你正在挑选三个提交.Git只是一次一个地做三个.在第一次樱桃挑选期间,阶段#2是你的分支的尖端,阶段#3是第一次提交樱桃挑选的版本.一旦提交完成后,git就会进行新的提交,推进你的分支的提示.然后,在第二个樱桃选择期间,阶段#2是你的分支的尖端,这是你的第一个樱桃选择的提交,而阶段#3是从第二个提交被挑选的版本.对于最终提交,这再次重复.每次,阶段#3都是"他们的"版本.
然而,Rebase有点棘手.在内部,它首先让你进入一个新的,匿名的分支(一个"独立的HEAD").然后它运行git cherry-pick
以从原始分支中选择每个提交.这意味着"我们的"是分离的HEAD版本,而"他们的"是原始分支的版本.就像樱桃选择一样,这会反复重复每次提交的提交(字面意思是在交互式rebase的情况下,你编辑这些pick
行).一旦rebase完成,git只是简单地将分支标签洗牌,这样你刚刚创建的新匿名分支就是你的代码.
简而言之,您可以将rebase视为"扭转我们/他们的设置" - 但这是夸大其词.说第2阶段是新的融合代码可能更准确,第3阶段是您的旧代码.