git rebase 实现细节

Question

我试图弄清楚git-rebase. 文档提供了关于什么的信息git-rebase，但没有评论它是如何做的？

我查看了源代码，制定了一些测试用例，到目前为止了解以下内容：
1. Git 维护 rebase 的状态.git/rebase-apply（带有补丁、最终提交、头部名称等文件）
2. Git 用于git-format-patch创建所有必要的补丁文件（在 rebase-apply 里面）
3. Git 用来git-am一一应用这些补丁

我想我遗漏了很多细节。我在哪里可以找到实施细节？它只是简单地倾销补丁并天真地应用它吗？

Answer 1

你的总结基本完成了。Rebase其实比较简单。

1. 首先，计算要做的工作。这基本上是git rev-list <upstream>..<branch>为了确定需要移动的所有提交。
2. 在.git目录中的 state 文件夹中创建了执行 rebase 所需的信息。有两个主要的 rebase 后端，每个后端都使用不同的文件夹：
   • 对于应用变基（基于补丁，当前默认），每个提交的补丁将被生成并保存在 .git/rebase-apply
   • 对于合并变基（用于例如交互式变基），包含提交列表以及如何应用它们的待办事项列表将在 .git/rebase-merge
   • 对于这两个后端，会生成包含目标和原始提交的引用等信息的其他文件，并将其存储在状态文件夹中。
3. 接下来，HEAD分离并设置为onto提交（新的基础分支，您将在其中应用这些更改）。
4. 应用程序发生直到无法应用提交。
   • 对于基于补丁的变基，则按顺序应用补丁。如果补丁无法应用，那么 Git 将尝试代替cherry-pick有问题的提交。这是因为cherry-pick能够将合并冲突写入索引和工作目录。
   • 对于基于合并的变基，则提交是cherry-picked。
5. 如果 acherry-pick因冲突而失败，则 rebase 停止，您（用户）必须解决任何冲突并将git add它们写入索引。当您解决了所有冲突后，您就可以git rebase --continue.
6. 应用所有冲突后，将更新原始分支以指向最终的、重新提交的提交。

关于后端的一些结束细节：合并后端最初只是交互式 rebase 后端。它可以通过--merge选项手动调用，也可以用作其他的默认后端--onto。apply 后端较旧，最终可能会被合并后端完全取代。