git - git pull --rebase 默默地忽略变基冲突

Question

有人将此标记为重复，但它没有说明原因git rebase，因为没有冲突而git pull有

我有同一个 repo 的两个克隆，C1并且C2它们的 HEAD 都在提交时M1，对 file 有一些更改F。

假设没有.gitconfig文件，并且.git/config该文件是默认生成的git

在C1

1. 我修改F（在同一个地方M1修改F）
2. git commit -a --amend --no-edit重写M1，这会导致新的提交M2。
3. 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丢失。

标签： git

Answer 1

git merge 尝试查看点 M1 和 C1 之间的差异以及点 M1 和 C2 之间的差异，并将它们合并在一起。

git rebase 将您置于 M2 点，然后应用从点 M1 到点 C2 的每个更改，这些更改也不在顺序上到点 M2 的路径上。采用这种方法，它能够更好地理解什么是相关的，什么不是相关的，所以在合并方法中看起来像冲突的许多事情都更容易解决。

---

虽然许多开发人员似乎喜欢尽可能少地提交，但当涉及的每个提交都很小时， git rebase 实际上效果最好。对我来说，这一切都像是魔法，直到我尝试在 CVS 存储库上手动做同样的事情。同事 A 的更改，这只是一个单一的提交，并不能更容易地应用 rebase 概念，因为它是一回事。但是切换到他的更新，并应用同事 B 的几十个微小提交，效果很好，可以准确地显示每次更新的目的。