合并后的Git rebase混淆了已删除的文件

Question

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

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

如果我然后使用git rebase master将我的功能分支重新绑定到主服务器上，则会删除alpha，但我在功能分支上对alpha所做的更改现已应用于{{1} }！我收到了一个冲突警告，但很高兴解决了自动合并而没有阻止我提交审核的内容。

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

然后有三个相关问题：

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

我在Win7上运行Cygwin上的Git 1.7.9。我把一个transcript on pastebin显示在一个空目录中以beta开头，如果有人想查看自己的详细信息（由于长度我不会在这里发布）。

Answer 1

来自documentation for git-rebase：

  

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

当删除文件时，Git会认为是重命名的候选者，并尝试将重新定位的补丁应用于相应的重命名文件。听起来好像你的情况可能很糟糕。

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