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

Question

我的Git存储库有两个文件,alpha并且beta内容相同.

如果我alpha在我的主分支中删除,并在我的功能分支中编辑它,那么当我将master合并到功能中时,我就会发出冲突警告.假设我通过删除来解决这个问题alpha.

如果我然后将我的功能分支重新命名为master使用git rebase master,alpha则会被删除,但我alpha现在应用了对功能分支所做的更改beta!我收到了一个冲突警告但很高兴解决了自动合并而没有阻止我提交审核的提交.

有趣的是,如果我执行a git rebase -i并且只接受默认值,beta则不进行编辑,我将解决在合并时解决的相同冲突.

然后是三个相关问题:

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

我在Win7上运行Cygwin上的Git 1.7.9.我把一个成绩单放在pastebin上显示这个从git init一个空目录开始,如果有人想看到自己的详细信息(由于长度我不会在这里发布).

Answer 1

从以下文档git-rebase:

-m
--merge
使用合并策略进行rebase.当使用递归(默认)合并策略时,这允许rebase知道上游侧的重命名.

删除文件时,Git认为是重命名的候选者,并尝试将重新定位的补丁应用于相应的重命名文件.听起来它可能在你的情况下做出了糟糕的猜测.

您可以使用该-m选项选择其他合并策略.例如,resolve合并策略可以通过自动检测重命名来避免此问题(git-merge有关合并策略的详细信息,请参阅参考资料).