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