Question

简单方案：

远程：

git init
touch a.py && git add a.py && git commit -am "Add a.py"
touch b.py && git add b.py && git commit -am "Add b.py"

本地：

git clone REMOTE_URL
echo "Bob Loblaw" >> a.py && git commit -am "Append to a.py"

远程：

git rm a.py && git commit -am "Remove a.py"

本地：

git fetch origin
git rebase origin/master

输出：

$ cat b.py
Bob Loblaw

为什么我对a.py的本地更改应用于b.py而不是产生rebase冲突，例如。

CONFLICT (delete/modify): a.py deleted in HEAD and modified in Append to a.py. Version Append to a.py of a.py left in tree.

如果它有所作为，我正在使用git版本1.7.4.1。

Answer 1

之前我听说过这个奇怪的问题。

问题源于a.py和b.py内容相同的事实。

Git使用基于内容的启发式方法来检测文件重命名，在您的情况下，启发式操作混淆了删除a.py并将其重命名为b.py，因为它们都是空的，所应用的变化非常小。

这是因为默认的recursive合并策略，根据documentation，

可以检测并处理涉及重命名的合并

显然在现代版本的git中已经修复/改进了，因为在我的机器上我无法用Git v1.8.1.3重现这个问题。

您可以更新您的Git（强烈建议）或尝试使用其他合并策略，该策略不处理重命名，例如resolve（尽管它有一些缺点，请阅读文档以获取更多信息）。

修改

另一种替代方法是使用--rename-threshold合并策略的recursive选项，将其设置为M100%，根据git-diff的文档将< / p>

将检测限制为精确重命名

git命令是

git rebase -Xrename-threshold=M100% origin/master

Answer 2

在执行步骤时，我确实在rebase期间遇到了合并冲突（应该是这样）：

gittest/loc$ git rebase origin/master
[...]
CONFLICT (modify/delete): a.py deleted in HEAD and modified in Append to a.py.
Version Append to a.py of a.py left in tree.
Failed to merge in the changes.

你可能做了一些微妙的不同 - 或者你的git安装有问题或你的git中有bug（虽然这似乎不太可能）。

我在Debian Linux上使用了git 1.8.1.1。

Git rebase - 远程删除文件，本地rebase将更改应用于另一个文件

2 个答案: