git - 合并后的Git rebase对已删除的文件感到困惑

Question

我的 Git 存储库有两个文件，alpha和beta，内容相同。

如果我alpha在我的主分支中删除，并在我的功能分支中对其进行编辑，那么当我将主分支合并到功能时，我会收到有关冲突的警告。假设我通过删除来解决这个问题alpha。

如果我随后使用 将我的功能分支重新设置为 master git rebase master，alpha则会删除，但我alpha在功能分支上所做的更改现在将应用于beta！我收到一个冲突警告，但它很高兴通过自动合并解决，而不会阻止提交让我查看。

有趣的是，如果我执行 agit rebase -i并且只接受默认值，beta则不会对其进行编辑，并且我可以解决我在合并时解决的相同冲突。

那么三个相关的问题：

1. 为什么 Git 认为我应用于一个文件的更改应该应用于另一个文件，而另一个文件尚未被任何提交编辑？
2. 我怎样才能避免这种情况？
3. 为什么即使我采用默认选项，交互式 rebase 的行为也会有所不同？

我在 Win7 上的 Cygwin 上运行 Git 1.7.9。如果有人想自己查看详细信息，我已经在 pastebin 上放了一个成绩单，以git init在一个空目录中显示此内容（由于篇幅原因，我不在这里发布）。

Answer 1

从文档中git-rebase：

-m
--merge
使用合并策略来变基。当使用递归（默认）合并策略时，这允许 rebase 知道上游端的重命名。

当一个文件被删除时，Git 会考虑一个重命名的候选者，并尝试将重新定位的补丁应用于相应的重命名文件。听起来你的情况可能是一个糟糕的猜测。

您可以使用该-m选项来选择不同的合并策略。例如，resolve合并策略可以通过自动检测重命名来避免这个问题（git-merge有关合并策略的详细信息，请参阅）。