我在做git rebase -i --root，有时会发生冲突。我想了解它是如何工作的以及为什么会发生冲突。
据我所知，当 interactive rebase 正在进行时，它会将提交从提交列表的顶部应用到底部，因此我将其命名为 source 到target 其中 source 是要应用的当前提交，而 target 代表已经应用的提交。是正确的理解吗？如果是这样，那么如果与文件 'deleted by them' 旁边的消息有冲突，是否意味着该文件已在 source 中删除并在目标？所以，可能它在上次应用的提交中被编辑过，但在当前要应用的提交中被删除。
还有一个问题，是否可以查看已经应用了哪些提交？我的意思是在 target 中提交。
如果我对交互式变基的理解是错误的，并且我上面的所有细节都没有任何意义，我很抱歉，这个功能似乎让我感到困惑，所以我试图了解基本概念。
【问题讨论】：
标签： git git-rebase git-rewrite-history
...据我所知，当交互式变基正在进行时，它会将提交从提交列表的顶部应用到底部
是的：它首先对初始 (--onto) 提交进行分离的 HEAD 签出。1这将作为构建新提交链的点。
然后，对于每个pick 命令，它运行git cherry-pick。这是可能发生合并冲突的地方，因为 cherry-pick 使用 Git 的合并引擎。2此合并的 合并基础 是当前（分离的 HEAD）提交的父级。合并的--ours 侧是当前提交。合并的--theirs 一侧是被精心挑选的提交。
（当最后一个选择或其他命令完成并且一切顺利时，交互式变基移动分支名称以指向分离的HEAD，并将HEAD附加到该分支名称。）
...如果与“被他们删除”的文件旁边的消息发生冲突，是否意味着该文件已在源中删除并在目标中进行了编辑？所以，可能它在上次应用的提交中被编辑过，但在当前要应用的提交中被删除。
是的。在更典型的变基期间考虑这一点的一种方法是--theirs（或索引槽 3）是 your 提交。 --ours 提交通常也是您的一个旧提交的新副本，除了第一个被复制的提交，其中--ours 是来自--onto 目标的他们的提交。
还有一个问题，是否可以查看已经应用了哪些提交？我的意思是在目标中提交。
一种相对稳定且快捷的方法是运行git rebase --edit-todo，它会显示剩余的待办事项列表。这和“完成”列表不太一样，但如果你记得最初的待办事项列表，你可以通过减法在心理上恢复它。
其他选项包括使用当前（分离的）HEAD 和 git log：
git log [--oneline] onto-target..HEAD
显示到目前为止已复制的提交，或者在某些情况下，直接查看存储所有内容的 .git/rebase-* 目录（但最后一个位置已随时间移动）。
1当使用--root 时，交互式变基使用特殊情况而不是cherry-pick 进行第一次提交（必须是“pick”指令）。它必须，因为没有基本提交就不能使用git cherry-pick。所以它只是从第一个要被挑选的提交中抓取树，并从该树中进行新的根提交。这一步必须始终成功：这里不可能发生冲突。完成这一步意味着从要选择的提交列表中删除第一个提交，之后变基继续正常进行。
2Cherry-pick 直接调用合并策略，例如git merge-recursive，而不是运行git merge。这有很多技术原因，但主要的两个是这种方式，cherry-pick 自己选择合并基础，并且这种方式，cherry-pick 自己在合并完成后进行最终提交，作为常规非-合并提交。
【讨论】：