交互式变基 git
Interactive rebasing git
我正在做 git rebase -i --root，有时会发生冲突。我想了解它是如何工作的以及为什么会发生冲突。
据我所知，当 interactive rebase 正在进行时，它会将提交从提交列表的顶部应用到底部，所以我将其命名为 source 到 target 其中 source 是要应用的当前提交，target 代表已经应用的提交。是正确的理解吗？如果是这样，那么如果与文件“已被他们删除”旁边的消息存在冲突，是否意味着该文件已在 source 并在 目标 中编辑？因此，可能它已在上次应用的提交中进行了编辑，但在要应用的当前提交中被删除了。
还有一个问题，是否可以查看已经应用了哪些提交？我的意思是在 target.
中提交
如果我对交互式变基的理解是错误的并且我上面的所有细节都没有任何意义，我很抱歉，这个功能似乎让我感到困惑，所以我试图了解基本概念.
... as I understand when the interactive rebase is in progress it applies commits from the top of the commit list to the bottom
是：它首先对初始 (--onto) 提交执行分离的 HEAD 检查。1 这是新提交链的起点建成。
然后，对于每个 pick 命令，它 运行s git cherry-pick。这是可能发生合并冲突的地方，因为 cherry-pick 使用 Git 的合并引擎。2 本次合并的 merge base是当前（分离的 HEAD）提交的父级。合并的 --ours 端是当前提交。合并的 --theirs 端是精心挑选的提交。
(当最后一个 pick 或其他命令完成并且一切顺利时，交互式 rebase 将分支名称移动到指向分离的 HEAD，并将 HEAD 附加到该分支名称.)
... if there is a conflict with the message next to a file 'deleted by them' does it mean that the file has been deleted in the source and edited in the target? So, probably it has been edited in the last applied commit, but deleted in the current commit to be applied.
是的。在更典型的变基期间考虑这一点的一种方法是 --theirs （或索引槽 3）是 你的 提交。 --ours 提交通常也是旧提交的新副本，除了第一个提交被复制，其中 --ours 是 他们的 提交来自 --onto目标。
One more question, is it possible to see which commits have been already applied? I mean commits in the target.
一个相对稳定和快速的方法是运行 git rebase --edit-todo，它会显示剩余的待办事项列表。这与 "done" 列表不太一样，但如果您还记得原来的待办事项列表，您可以通过减法在心理上恢复它。
其他选项包括使用当前（分离的）HEAD 和 git log:
git log [--oneline] onto-target..HEAD
显示到目前为止已复制的提交，或者在某些情况下，直接查看存储所有内容的 .git/rebase-* 目录（但最后一个位置随时间移动）。
1当使用 --root 时，交互式变基使用特殊情况而不是 cherry-pick 第一次提交（必须是 "pick" 操作说明）。它必须，因为 git cherry-pick 不能在没有基本提交的情况下使用。所以它只是从第一个要选择的提交中获取树，并从该树中创建一个新的根提交。此步骤必须始终成功：此处不可能发生冲突。完成此步骤意味着从要选择的提交列表中删除第一个提交，之后 rebase 将继续正常进行。
2Cherry-pick 直接调用合并策略，例如 git merge-recursive，而不是 运行ning git merge。这有很多技术原因，但主要的两个是这样，cherry-pick 本身选择合并基础，这样，cherry-pick 本身在合并完成后进行最终提交，作为一个常规的非-合并提交。
我正在做 git rebase -i --root，有时会发生冲突。我想了解它是如何工作的以及为什么会发生冲突。
据我所知，当 interactive rebase 正在进行时，它会将提交从提交列表的顶部应用到底部，所以我将其命名为 source 到 target 其中 source 是要应用的当前提交，target 代表已经应用的提交。是正确的理解吗？如果是这样，那么如果与文件“已被他们删除”旁边的消息存在冲突，是否意味着该文件已在 source 并在 目标 中编辑？因此，可能它已在上次应用的提交中进行了编辑，但在要应用的当前提交中被删除了。
还有一个问题，是否可以查看已经应用了哪些提交？我的意思是在 target.
中提交如果我对交互式变基的理解是错误的并且我上面的所有细节都没有任何意义，我很抱歉，这个功能似乎让我感到困惑，所以我试图了解基本概念.
... as I understand when the interactive rebase is in progress it applies commits from the top of the commit list to the bottom
是：它首先对初始 (--onto) 提交执行分离的 HEAD 检查。1 这是新提交链的起点建成。
然后，对于每个 pick 命令，它 运行s git cherry-pick。这是可能发生合并冲突的地方，因为 cherry-pick 使用 Git 的合并引擎。2 本次合并的 merge base是当前（分离的 HEAD）提交的父级。合并的 --ours 端是当前提交。合并的 --theirs 端是精心挑选的提交。
(当最后一个 pick 或其他命令完成并且一切顺利时，交互式 rebase 将分支名称移动到指向分离的 HEAD，并将 HEAD 附加到该分支名称.)
... if there is a conflict with the message next to a file 'deleted by them' does it mean that the file has been deleted in the source and edited in the target? So, probably it has been edited in the last applied commit, but deleted in the current commit to be applied.
是的。在更典型的变基期间考虑这一点的一种方法是 --theirs （或索引槽 3）是 你的 提交。 --ours 提交通常也是旧提交的新副本，除了第一个提交被复制，其中 --ours 是 他们的 提交来自 --onto目标。
One more question, is it possible to see which commits have been already applied? I mean commits in the target.
一个相对稳定和快速的方法是运行 git rebase --edit-todo，它会显示剩余的待办事项列表。这与 "done" 列表不太一样，但如果您还记得原来的待办事项列表，您可以通过减法在心理上恢复它。
其他选项包括使用当前（分离的）HEAD 和 git log:
git log [--oneline] onto-target..HEAD
显示到目前为止已复制的提交，或者在某些情况下，直接查看存储所有内容的 .git/rebase-* 目录（但最后一个位置随时间移动）。
1当使用 --root 时，交互式变基使用特殊情况而不是 cherry-pick 第一次提交（必须是 "pick" 操作说明）。它必须，因为 git cherry-pick 不能在没有基本提交的情况下使用。所以它只是从第一个要选择的提交中获取树，并从该树中创建一个新的根提交。此步骤必须始终成功：此处不可能发生冲突。完成此步骤意味着从要选择的提交列表中删除第一个提交，之后 rebase 将继续正常进行。
2Cherry-pick 直接调用合并策略，例如 git merge-recursive，而不是 运行ning git merge。这有很多技术原因，但主要的两个是这样，cherry-pick 本身选择合并基础，这样，cherry-pick 本身在合并完成后进行最终提交，作为一个常规的非-合并提交。