我有两个分支A/B：
1.在分支A中提交一个名为a的提交
1.检出分支B，并合并A
1.恢复提交a（到目前为止，B没有提交a，但A有）
- checkout
A，恢复提交a，但是用git cherry-pick a重新提交a（现在A已经提交了a'） - checkout
B，再次将A合并到B（提交a或a'丢失）
我想最后，分支B将有提交a或a'，但是它丢失了，这是怎么回事？
我已经检查了git文档，但它只是提到了三种方式合并，没有任何细节。
来自https://git-scm.com/docs/git-merge#_description：
然后“git merge topic“将重放在topic分支上所做的更改，因为它与master发生了分歧（即E），直到其当前提交（C）在master之上，并在新提交中记录结果沿着两个父提交的名称和来自用户的描述更改的日志消息。操作时，将ORIG_HEAD设置为当前分支的尖端（C）。
如果它是一个实际的replay，提交a应该在分支B上。
1条答案
按热度按时间iklwldmw1#
你有这样的历史：
字符串
您发现分支B中缺少
a'（与a相同）的更改。这是预期的，而不是错误。
当Git合并更改时，它只考虑两个项目状态，一个是合并，分支A上的
a'和分支B上的a_rev2，另一个是合并基础，即a。从分支B的Angular 来看（“合并目标”），只有合并基a和另一个分支尖端之间的变化，a'被考虑，只有那些更改被集成到“合并目标”中。由于a_rev1和a'是相互抵消的更改，因此实际上没有要集成的更改，因此，合并X1 m9n1x与祖先X1 m10n1x相比不引入任何改变。你也可以这样读这个故事：
1.在分支A上，开发人员首先说“我需要恢复
a，所以让我们创建a_rev1！”但是后来，他们说“不，等等，我确实需要a，所以让我们选择它，a'！”结果是我们不需要任何更改。1.在分支B上，开发人员说：“我们肯定需要恢复
a，让我们生成a_rev2。1.分支现在合并了。一方说，不需要改变，但另一方说需要一些改变，
a_rev2，所以这就是剩下的。