问题
My Git repository has two files, alpha and beta, with identical content.
If I delete alpha in my master branch, and edit it in my feature branch, then when I merge master into feature, I'm warned about a conflict. Assume I resolve this by deleting alpha.
If I then rebase my feature branch onto master using git rebase master, alpha is deleted, but the changes I made to alpha on the feature branch are now applied to beta! I get a conflict warning but it's happily resolved with an auto-merge without the commit being blocked for me to review.
Interestingly, if I do a git rebase -i and just accept the default, beta isn't edited and I get to resolve the same conflict I resolved at merge time.
Three related questions then:
- Why does Git think the change I applied to one file should be applied to another, when the other hasn't been edited by any commit?
- How can I avoid this sort of situation?
- Why is the behaviour different for an interactive rebase, even when I take the default options?
I'm running Git 1.7.9 on Cygwin on Win7. I've put a transcript on pastebin showing this starting with a git init in an empty directory, if anyone wants to see the details for themselves (I'm not posting it here due to length).
回答1:
From the documentation for 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.
When a file is deleted, Git considers that a candidate for a rename, and tries to apply the rebased patch to the corresponding renamed file. It sounds like it might have made a poor guess in your case.
You can use the -m option to select a different merge strategy. For example, the resolve merge strategy may avoid this problem with auto-detecting renames (see git-merge for details on merge strategies).
来源：https://stackoverflow.com/questions/11985346/git-rebase-after-merge-confused-about-deleted-file