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

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

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

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

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

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

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

如果你想看到完全相同的历史，你 应该使用归并。Merge保存历史，而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不能叠加。(另一个大优点)