有人将此标记为重复，但是并不能说明为什么git rebase没有冲突，而git pull却有冲突
我有两个相同仓库的克隆，C1和C2，它们的HEADs都在提交M1上，对文件F进行了一些更改。
假设没有.gitconfig文件，并且该文件的.git/config是git生成的默认值
C1 F（与M1修改了F的位置相同）git commit -a --amend --no-edit重写M1，这将导致新的提交M2。 git push -f覆盖遥控器。C2 git fetch。因此origin/master == M2而HEAD == M1 由于M1和M2都修改了F，因此以下任何命令都将进入merge conflict状态：
git merge origin/master git merge git rebase origin/master git pull 但是，以下命令不会触发merge conflicts并将HEAD设置为M2
git rebase git pull --rebase git rebase和git rebase origin/master有什么区别git pull --rebase的作用是什么？ 以前，我一直以为
git pull与git fetch && git merge origin/master git pull --rebase与git fetch && git rebase origin/master 但是这个实验使我的想法无效。
即使我在M3上方再提交一个M2并推入C1，情况也不会改变。在C2中，它将仍然重置为M3，并且M1丢失。
答案 0 :(得分：0)
git merge尝试查看点M1和C1之间的差异以及点M1和C2之间的差异，并将它们合并在一起。
git rebase将您置于点M2，然后将从点M1到点C2的每个更改依次应用于不在点M2的路径上。采用这种方法，可以更好地了解相关的内容和不相关的内容，因此看起来很明显的合并方法中的许多事情都可以解决。
尽管许多开发人员似乎希望尽可能少地进行提交，但是当涉及的每个提交都很小时，git rebase实际上最有效。在我看来，这一切似乎都是不可思议的，直到我尝试在CVS存储库上手动完成基本上相同的事情为止。同事A的更改只是一次提交，对于rebase概念的应用并不容易，因为这是一回事。但是切换到他的更新，并应用同事B的数十个微小提交，就很好地显示了每次更新的意图。