假设最初有3个提交，A,B,C:

然后开发人员Dan创建了提交D，开发人员Ed创建了提交E:

显然，这种冲突应该以某种方式解决。对此，有两种方法:

走：

提交D和E仍然在这里，但是我们创建了合并提交M，它继承了D和E的更改。然而，这创建了菱形，许多人对此感到非常困惑。

变基:

我们创建提交R，其实际文件内容与上面合并提交M的内容相同。但是，我们摆脱了提交E，就像它从未存在过一样(用圆点-消失线表示)。由于这种删除，E对于开发人员Ed来说应该是本地的，并且不应该被推送到任何其他存储库。rebase的优点是避免了菱形，历史保持良好的直线-大多数开发人员都喜欢这样!

假设你已经在你的特性分支中提交了3次，当你想要将你的特性分支更改发送到主分支时。 你有两个选择

git merge:在这种情况下，主分支将只接收1次提交(合并3次提交) git rebase:在这种情况下，main branch将接收3次提交

我发现了一篇关于git rebase vs merge的非常有趣的文章，想在这里分享一下

如果你想看到完全相同的历史，你 应该使用归并。Merge保存历史，而rebase重写历史。 合并会向历史记录中添加一个新的提交 重基可以更好地简化复杂的历史记录，你可以通过交互的重基来改变提交历史。

为了便于理解可以看到我的身影。

Rebase将改变提交哈希，因此如果你想避免大量冲突，只需在分支完成/完成时使用Rebase作为稳定。

Git rebase更接近于merge。rebase的区别是:

本地提交被临时地从分支中移除。 运行git pull 再次插入所有本地提交。

这意味着所有本地提交都被移动到最后，在所有远程提交之后。如果您遇到合并冲突，也必须解决它。

虽然被广泛接受且获得最多好评的答案很棒，但我发现仅用语言来解释两者的差异是有用的:

走

“好吧，我们的存储库有两种不同的开发状态。我们把它们合并在一起。两个父母，一个孩子。”

变基

“Give the changes of the main branch (whatever its name) to my feature branch. Do so by pretending my feature work started later, in fact on the current state of the main branch.” “Rewrite the history of my changes to reflect that.” (need to force-push them, because normally versioning is all about not tampering with given history) “Likely —if the changes I raked in have little to do with my work— history actually won't change much, if I look at my commits diff by diff (you may also think of ‘patches’).“

总结:在可能的情况下，rebase几乎总是更好的。使重新集成到主分支更容易。

因为?➝你的特性工作可以呈现为一个大的“补丁文件”(又名diff)相对于主分支，不需要“解释”多个父:至少两个，来自一个合并，但可能更多，如果有几个合并。与合并不同，多个rebase不能叠加。(另一个大优点)