我最近开始使用 git 树和临时索引文件来构建提交，而无需修改我的工作目录，以实现某些任务的自动化。最终目标是有效地变基一些分支（例如feature/x_y_z，在 之上main），但不修改工作目录来完成它。显然我仍然想检测冲突，并且绝对不会破坏更改main（因为可以使用git commit-tree）。我通读了本书的“Git Internals”一章，它对树、blob、索引等很有教育意义——但没有明确解释变基是如何工作的。
（旁白：这样做的动机是 1）它更快，以及 2）我想让开发人员能够快速启动一些提交/分支的测试，使用最新的规范更改，而不会破坏他们的工作目录。）
为此，如何git rebase在引擎盖下工作？它使用什么管道命令？它如何分析树以检测冲突？指向有用资源的链接和/或对这些内容的直接解释将非常有帮助。
为此， git rebase 如何在幕后工作？
情况很复杂。由于历史原因，它特别复杂：它最初是一个使用git format-patchand的小型 shell 脚本git am，但它有一些缺陷，因此它被重写为一组更精美的 shell 脚本。其中包括基于合并的后端和交互式后端，将am基于旧的后端拆分为第三个变体。从那时起，它再次被用 C 重写，以使用 Git 所称的sequencer。交互式代码也被设计为允许重新执行合并。我将忽略这些案例，因为它们更难绘制和解释。
它使用什么管道命令？
现在它已经用 C 重写了，它不再使用它们中的任何一个。
在过去，交互式后端主要使用git cherry-pick（从技术上讲，这不是一个管道命令），加上git commit --amend用于壁球操作，在git rev-list用于收集提交的哈希 ID 以使用cherry-pick 复制之后。
现在正在修改 C 变体以构建越来越多的部分（主要是为了让 Windows 上的事情变得更快），但目前仍然单独调用合并。
它如何分析树以检测冲突？
这是 的基本工作git cherry-pick：它调用git merge但将合并基础设置为被复制提交的父级。此时的当前提交是被扩展以实现rebase的分支尖端的提交。
也就是说，我们有一些类似的东西：
H--I--J <-- to-copy (HEAD)
/
...--o--o--o <-- optional-random-other-stuff-cluttering-up-the-diagram
\
A--B--C <-- target
我们要“变基”的分支是由名称标识的分支to-copy；我们希望副本出现在之后的提交是 commit C。所以我们运行：
git checkout to-copy
确保我们从正确的地方开始，然后运行：
git rebase target
或者，如果我们所拥有的看起来像这样：
...--A--B--C <-- main
\
D--E--F--G <-- feature1
\
H--I--J <-- to-copy (HEAD)
我们想复制只是H-I-J为了在 之后登陆C，我们运行：
git rebase --onto main feature1
以便D-E从副本列表中排除提交。
Hrebase 操作首先生成要复制的提交哈希 ID 的列表，在这种情况下，通过Jinclusive提交的实际原始哈希 ID 。
Rebase 通常会从这个列表中省略某些提交：
-ror选项）；-p和git patch-id中与对称差异另一半中的提交匹配的任何提交也将被省略。1对于大多数简单的线性提交链，这个省略步骤根本没有任何作用；我在这里说明的提交就是这种情况。
构建了要复制的提交哈希 ID 列表后，rebase 现在将--onto目标提交签出C为分离的 HEAD。如果没有--onto参数，则目标提交是命令upstream后的参数指定的git rebase，或者是 HEAD 分离步骤之前分支的上游指定的提交。所以，对于更复杂的--onto变体，我们现在有这个：
...--A--B--C <-- main, HEAD
\
D--E--F--G <-- feature1
\
H--I--J <-- to-copy
HRebase 现在以适当且必要的顺序（首先，然后I，然后J）一次一个地挑选每个要复制的提交。这些cherry-pick操作中的每一个都像处理一样处理git merge，但是具有特殊的强制合并基础提交。我稍后会详细介绍，但让我们假设精选的H工作并进行新的提交；让我们调用新的 commit H'，以表明它是 的“副本” H，并将其绘制在：
H' <-- HEAD
/
...--A--B--C <-- main
\
D--E--F--G <-- feature1
\
H--I--J <-- to-copy
我们现在用I和重复这个，J得到：
H'-I'-J' <-- HEAD
/
...--A--B--C <-- main
\
D--E--F--G <-- feature1
\
H--I--J <-- to-copy
复制最后一个要复制的提交后，将原始分支git rebase的名称J从原始提交中拉出并将其粘贴到最终复制的提交上，在这种情况下J'，然后重新附加 HEAD：
H'-I'-J' <-- to-copy (HEAD)
/
...--A--B--C <-- main
\
D--E--F--G <-- feature1
\
H--I--J ???
由于没有名称可以找到 commit J，它从我们的视图中消失了，现在看来 Git 以某种方式更改了三个提交。（它还没有——原件仍在存储库中。您可以通过 reflogs 或通过 找到它们ORIG_HEAD，尽管 rebase 的 C 重写引入了一个ORIG_HEAD有时是错误的错误。）
1使用的实际对称差异HEAD...target或多或少是 。（因为它是对称的，所以你可以交换左右两边，只要你记得哪一边是哪一边。）所以这些是计算了它们的补丁 ID 的提交。Git 甚至可以为合并提交计算补丁 ID，尽管 rebase 通常会忽略合并。当您告诉它复制合并时，我从来没有深入了解它是否确实计算它们，如果合并提交确实有重复，在这种情况下会发生什么，但这是一个有趣的问题。
为了理解挑选樱桃，让我们从一个更正常的日常操作开始：真正的合并。当我们进行真正的合并时，我们正在合并工作。假设我们有以下提交图：
I--J <-- br1 (HEAD)
/
...--G--H
\
K--L <-- br2
也就是说，我们有两个分支br1和br2，每个分支都有自己的两个提交，它们遵循以 commit 结尾的一些共享提交序列H。
正如你现在通过阅读 Git 内部知识所知道的，每个提交都有每个文件的完整快照。作为一个快照，而不是一组更改，没有明显的方法可以将快照视为更改，直到您意识到 Git 所做的就是一遍又一遍地玩Spot the Difference的游戏。我们将两个提交放在某个地方，作为两个快照，然后以编程方式观察每个提交并找出发生了什么变化。就是git diff这样。
现在，如果我们运行从 commitH到 commit的差异J，这将告诉我们这两个快照之间发生了什么变化。就其本身而言，这并不是特别有用，但假设我们将这些信息保存在某个地方。让我们运行：
git diff --find-renames <hash-of-H> <hash-of-J> # what we changed
找出br1自 commit 以来我们所做的更改H。我们会将所有这些保存在某个地方，可能是一个临时文件或（如果我们有足够的内存）内存。
现在让我们重复这个操作，但是用 commit 的哈希值L代替：
git diff --find-renames <hash-of-H> <hash-of-L> # what they changed
这告诉我们发生了什么br2。
如果我们将更改加在一起，注意只复制两个分支上的任何给定更改的副本，并将两组更改的总和应用于快照H，我们将获得正确的合并结果。2
那么，这正是 merge 所做的。它只运行两个差异——--find-renames用于查找任何树范围的文件重命名操作，以便它知道合并库中的文件与左侧和/或右侧提示提交中的old/path/to/file“相同文件” ——然后合并更改new/name/of/it-sets 来自两个差异，将它们应用于每个文件。3
如果合并顺利，并且合并没有被 禁止--no-commit，4 Git 将继续自己进行合并提交M。而不是普通的单亲，在这种情况下是 commit J，合并提交有两个父母。第一个是普通的，第二个是另一个分支提示提交， commit L：
I--J
/ \
...--G--H M <-- br1 (HEAD)
\ /
K--L <-- br2
合并完成。
如果有冲突，Git 会在它的索引（扩展的槽保持扩展）和你的工作树中留下一团糟：内置的等效物git merge-file已经在你的工作树文件上乱涂乱画，以便对正确的合并进行最佳猜测, 加上合并冲突标记和两个部分 - 或merge.conflictStyle设置为diff3, 所有三个 - 存在合并冲突的输入文件。
请注意，使用-X ours或-X theirs告诉 Git 通过盲目地选择我们或他们的一方来解决冲突的部分。这只会影响这些低级冲突：添加/添加、修改/删除以及其他高级或树级冲突仍会导致合并停止并获得帮助。
（对于cherry-pick，这些选项目前都是通过git-merge-recursive后端处理的，没有办法选择任何其他合并后端。对于git merge，-s参数，例如，，git merge -s abcd使Git尝试运行git-merge-abcd。当然没有git-merge-abcd后退以目录结尾git --exec-path，所以这只会失败，但这里的重点是常规合并允许您选择策略。递归合并只是默认值。樱桃采摘不允许选择策略。）
2当然，对于“正确”的一些定义。Git 完全基于行：差异是逐行的，而合并是逐行进行的。
3好吧，这就是高级概述。在内部，它一次性完成重命名查找，然后根据需要进行高级或树级文件名的处理——这也处理文件创建和删除，并检测添加/添加、修改/删除、重命名/重命名和其他这样的冲突——然后继续使用git merge-file内置的单独的第二遍来合并每个单独的三个文件组：merge-base、ours 和 theirs。合并过程发生在 Git 的index中，该索引临时扩展为最多容纳每个文件的三个副本，并带有插槽编号，以区分哪个是合并基础版本（插槽 1），哪个是--ours版本（插槽 2），哪个是--theirs版本（插槽 3）。
4请注意，--squash打开--no-commit并且目前无法再次将其关闭，因此最后--squash总是需要手册git commit。
为了实现挑选，Git 只需使用强制父级运行其合并引擎。
假设我们有这个提交图：
...--o--P--C--o--...
...
...--G--H <-- cur-branch (HEAD)
我们在当前分支上cur-branch，以 commitH作为它的提示 commit，所以 commitH就是当前的 commit。我们现在运行：
git cherry-pick <hash-of-C>
Git 所做的是找到C的父P级并将其用作标准合并操作的假合并基础，但请确保在合并过程结束时，我们进行正常的非合并提交：
...--o--P--C--o--...
...
...--G--H--C' <-- cur-branch (HEAD)
CommitC'最终成为 commit 的“副本” C。要了解原因，让我们看看出现了哪些差异。
git diff --find-renames <hash-of-P> <hash-of-H> # what we changed
git diff --find-renames <hash-of-P> <hash-of-C> # what they changed
现在，找到“他们改变了什么”似乎很自然。如果他们在某个文件的第 42 行之后添加了一行，这就是我们想要在这里做的。所以这个差异很有意义。但一开始发现“我们改变了什么”似乎有点奇怪。但事实证明，这正是我们所需要的。
如果他们只更改了一个文件的一行，我们想知道：我们是否触及了该文件的同一行？ 如果不是，这些更改很好地结合在一起：我们接受所有更改，将所有文件转换P为匹配 中的所有文件H，这让我们返回提交H；然后我们将他们所做的一项更改添加到一个文件中，同时还需要进行任何行号调整，并将他们所做的更改添加到一个文件中。所以这是完全正确的。
如果我们都接触了该文件的同一行，我们就会在该行上发生合并冲突。这也完全正确。
当我们思考所有可能的变化时——包括文件重命名之类的事情——我们会发现，确实，做一个 diff from PtoH是正确的做法。这就是我们这样做的原因。这也意味着我们可以使用现有的合并代码。
当然，现有的合并代码在索引上/中进行操作，并将我们的工作树用作临时存储。这就是变基相对缓慢和痛苦的原因。改善这一点的唯一真正方法是直接在内存中进行更多的合并工作。现在有人在这样做：在Git 邮件列表中搜索 Elijah Newren 的“merge-ort” 。