git重基实现细节

Question

我试图找出git-rebase的工作机制。文档提供了关于git-rebase做什么的信息，但是没有评论它是如何做的？

我研究了源代码，编写了一些测试用例，到目前为止了解了以下内容：

1. Git在.git/rebase-apply中维护重基状态(包括修补程序、最终提交、头名等文件)。
2. Git使用git-format-patch创建所有必需的修补程序文件(在rebase-apply中)
3. Git使用git-am逐个应用这些修补程序。

我想我漏掉了很多细节。在哪里可以找到实现细节？它只是简单地抛出修补程序并天真地应用它吗？

Answer 1

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

1. 首先，计算要做的工作。这基本上是git rev-list <upstream>..<branch>，用于标识需要移除的所有提交。
2. 执行重基所需的信息是在.git目录的状态文件夹中创建的。有两个主重基后端，每个后端使用不同的文件夹：
   • 对于应用程序重基(基于修补程序的修补程序，目前是默认的)，每个提交的补丁将生成并保存在.git/rebase-apply中。
   • 对于合并重基(用于交互重基)，将在.git/rebase-merge中生成包含提交列表和如何应用它们的待办事项列表。
   • 对于两个后端，生成其他包含信息的文件，例如对目标和原始提交的引用，并将其存储在状态文件夹中。

3. 接下来，HEAD被分离并设置为onto提交(新的基本分支，您将在其中应用这些更改)。
4. 应用程序在无法应用提交之前进行。
   • 对于基于补丁的重基，则按顺序应用修补程序。如果某个修补程序无法应用，那么Git将尝试替代cherry-pick进行所讨论的提交。这是因为cherry-pick能够将合并冲突写入索引和工作目录。
   • 对于基于合并的重基，则提交是cherry-pick编辑的。

5. 如果cherry-pick因冲突而失败，则重基将停止，您(用户)必须解决任何冲突，并将它们放到索引中。当您解决了所有的冲突，您可以git rebase --continue。
6. 一旦应用了所有冲突，原始分支就会被更新，以指向最终的、基于重新的提交。

关于后端的一些结束细节:合并后端最初只是交互式的重基后端。它可以使用--merge选项手动调用，也可以用作--onto的默认后端等。应用后端较旧，最终可能完全被合并后端所取代。