git rebase master 功能会产生（重命名/删除）冲突，而 git rebase -i master 功能则不会

我在使用 git 时遇到了一种奇怪的情况，其中我有一个功能分支修改了一些文件并删除了一个文件“foo.js”。当我通过“git rebase master feature”重新基于master时，我遇到了以下类型的冲突：

CONFLICT (rename/delete): src/main/resources/com/blah/bar.js deleted in Change some js and renamed in HEAD. Version HEAD of src/main/resources/com/blah/bar.js left in tree.

奇怪的是，master 分支和 feature 分支都没有修改过 bar.js，更不用说删除它了。更重要的是，执行“git rebase -i master feature”不会产生冲突（当选择所有“pick”时）。

一个可能的重要线索是 foo.js 和 bar.js 是相似但不完全相同的文件，稍加修改的文件也与 foo.js 和 bar.js 相似。我唯一可以做出的疯狂猜测是，对相关 js 文件所做的一些更改在某种程度上使 git 误以为分支功能中的违规提交包括删除 bar.js，然后重命名 foo.js（这是删除）到 bar.js。这可能/预期吗？有谁知道为什么会发生这种情况？仅供参考，我在 linux mint 16 上使用 git 版本 1.8.3.2。

That is有点不寻常，但你的诊断是正确的。

交互式变基使用一系列git cherry-pick命令。非交互式变基使用git-merge-recursive（至少默认情况下；请参阅git-rebase--merge脚本中的git-core目录，无论它位于系统上的任何位置，或者只需记下-s <strategy>论证git rebase）从旧的提交中进行每一次新的提交。作为文档-m / --merge说（尽管它没有提到这是default):

       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.
 
       Note that a rebase merge works by replaying each commit from the
       working branch on top of the <upstream> branch. Because of this,
       when a merge conflict happens, the side reported as ours is the
       so-far rebased series, starting with <upstream>, and theirs is the
       working branch. In other words, the sides are swapped.

You can tell for sure by using git diff -M --name-status¹ to compare the suspect commit pair. If this shows bar.js as Deleted and foo.js as Renamed to bar.js, that's the culprit.

令人烦恼的是，无法设置合并的重命名阈值。幸运的是，解决方法只是运行交互式变基并且不对命令系列进行任何更改，您可以通过执行以下操作来简化操作：

GIT_EDITOR=: git rebase -i ...

或通过使用-p保留合并的选项（如果有合并，后者会有所不同，但具有执行“隐式交互式”变基的副作用，它只是设置GIT_EDITOR=:并且还关闭自动挤压）。

¹The -M option is not required if you have configured diff.renames to true (see git config documentation https://www.kernel.org/pub/software/scm/git/docs/git-config.html). Merge-recursive internally sets the rename but not copy detection, and sets the "rename limit" the first of whichever of these applies: your configured merge.renamelimit, if you have one; your diff.renamelimit if you have one; or the constant 1000.