git中git-rebase的工作机制

git diff a46c3 169a6 和 git diff da985 e57cf

现在,这些变化不一定能被清晰地应用。什么时候? rebase 运行到一个没有应用补丁程序的提交中,您会遇到冲突,就像合并一样,它会要求您解决冲突,然后运行 git rebase --continue 移动它们。

希望这是一次真正的合并行动。这里有一些实现细节,但结果是git尽可能利用其合并功能。虽然最终的结果是移植169a6使其成为e57cf,但是 目录 可以通过将169a6与da985合并来创建提交e57cf的一部分,因为它们有一个共同的祖先a47c3,所以三方合并是可能的。这使得回扣可以在您可能预期的某些时间避免冲突。

实现细节,如果您感兴趣的话:默认情况下,rebase使用 git-format-patch 创建差异,然后使用 git-am --3way 选项,将其指示为“如果修补程序记录了它应该应用到的blob的标识,并且我们在本地有这些blob可用,则返回到3路合并”。还可以告诉rebase在内部使用合并策略,在这种情况下,它直接调用合并策略(默认情况下是递归的)。无论哪种方式,它都比简单地转储补丁并天真地应用它更复杂。

(最后一段一半来自记忆,一半来自略读git rebase的源代码,现在已经很晚了-如果有更了解情况的人经过,请随时更正任何不准确或遗漏。)