git rebase实现细节

Question

我想弄清git-rebase的工作机制。 Documentation提供有关git-rebase的功能的信息，但不对它的操作方式发表评论？

我特地到source code，摸索出一些测试用例到目前为止明白以下几点：
1.混帐保持底垫的状态.git/rebase-apply（与像补丁文件，最后提交，头名等）
2. Git使用git-format-patch创造一切必要的补丁文件（这是内底垫申请）
3. Git使用git-am一个

应用这些补丁一个我觉得我缺少了很多的细节。我在哪里可以找到实施细节？它是简单地倾销这个补丁并且天真地应用它吗？

Answer 1

你的总结基本完成。实际上，相对简单。

1. 首先，计算待完成的工作。这基本上是git rev-list <upstream>..<branch>来标识需要移动的所有提交。
   1. 如果您正在执行正常（基于补丁）的rebase，那么每个提交的补丁都会生成并保存在rebase状态文件夹（.git/rebase-apply）中。
   2. 如果您使用git rebase --merge调用了rebase，则提交将存储在不同的状态文件夹（.git/rebase-merge）中。
2. 接下来，HEAD被分离并设置为onto提交（新基地分支，在这里您将应用这些更改）。
3. 应用程序发生，直到提交不能应用。
   1. 如果您正在执行基于修补程序的rebase，则会按顺序应用修补程序。如果修补程序未能应用，那么Git将尝试改为提交有问题的cherry-pick。这是因为cherry-pick能够将合并冲突写入索引和工作目录。
   2. 如果你正在做一个基于合并的rebase，那么提交是cherry-pick ed。
4. 如果cherry-pick失败，冲突，重订停止，您（用户）必须解决任何冲突和git add他们的索引。当您解决所有冲突时，您可以git rebase --continue。
5. 一旦应用了所有冲突，原始分支将更新为指向最终的重新提交的提交。