merge 后的 Git rebase 对已删除的文件感到困惑

Question

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

如果我在我的 master 分支中删除 alpha，并在我的 feature 分支中编辑它，那么当我将 master merge 到 feature 时，我会收到冲突警告。假设我通过删除 alpha 来解决这个问题。

如果我随后使用 git rebase master 将我的功能分支 rebase 到 master，alpha 将被删除，但我对 alpha 所做的更改是功能分支现在应用于 beta!我收到了一个冲突警告，但很高兴通过自动 merge 解决了这个问题，没有阻止提交供我审查。

有趣的是，如果我执行 git rebase -i 并只接受默认值，beta 不会被编辑，我将解决与 merge 时解决的相同冲突时间。

然后是三个相关的问题:

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

我在 Win7 的 Cygwin 上运行 Git 1.7.9。我放了一个 transcript on pastebin在空目录中以 git init 开头显示此内容，如果有人想自己查看详细信息(由于篇幅，我不会在此处发布)。

Answer 1

来自documentation for git-rebase :

-m
--merge
Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side.

当一个文件被删除时，Git 认为它是重命名的候选者，并尝试将 rebased 补丁应用于相应的重命名文件。听起来它可能对您的情况做出了错误的猜测。

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