我在使用 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。
最佳答案
那有点不寻常,但你的诊断是正确的。
交互式 rebase 使用一系列 git cherry-pick
命令。非交互式 rebase 使用 git-merge-recursive
(至少在默认情况下;请参阅 git-rebase--merge
目录中的 git-core
脚本,无论它在您系统上的哪个位置,或者简单地记下 -s <strategy>
到 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. 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.
您可以使用 git diff -M --name-status
来确定1 比较可疑的提交对。如果这显示 bar.js
作为D
选择和 foo.js
作为R
命名为 bar.js
,这就是罪魁祸首。
恼人的是,没有办法设置 merge 的重命名阈值。幸运的是,解决方法是简单地运行一个交互式 rebase 并且不对命令系列进行任何更改,您可以通过以下方式进行快捷方式:
GIT_EDITOR=: git rebase -i ...
或使用 -p
保留 merge 的选项(如果您有 merge ,后者会有所不同,但具有执行“隐式交互” rebase 的副作用,它只设置 GIT_EDITOR=:
并关闭 autosquash)。
1-M
如果您已配置 diff.renames
,则不需要该选项至 true
(参见 git config
documentation)。 Merge-recursive 在内部设置重命名但不设置复制检测,并设置“重命名限制”中适用的第一个:您配置的 merge.renamelimit
, 如果你有;你的diff.renamelimit
如果你有;或常量 1000
.
关于git rebase master 特性给出(重命名/删除)冲突,git rebase -i master 特性没有,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/22951108/