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

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

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

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

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

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

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

走：

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

变基:

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

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

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

就我个人而言，我不认为标准的图表技术非常有用——箭头似乎总是指向错误的方向。(它们通常指向每次提交的“父”，这最终会在时间上倒退，这很奇怪)。

用语言解释一下:

When you rebase your branch onto their branch, you tell Git to make it look as though you checked out their branch cleanly, then did all your work starting from there. That makes a clean, conceptually simple package of changes that someone can review. You can repeat this process again when there are new changes on their branch, and you will always end up with a clean set of changes "on the tip" of their branch. When you merge their branch into your branch, you tie the two branch histories together at this point. If you do this again later with more changes, you begin to create an interleaved thread of histories: some of their changes, some of my changes, some of their changes. Some people find this messy or undesirable.

出于我不理解的原因，Git的GUI工具从来没有更清晰地呈现合并历史，抽象出单个合并。所以如果你想要一个“干净的历史”，你需要使用rebase。

我似乎记得读过一些只使用rebase的程序员和从不使用rebase的程序员的博客文章。

例子

我将用一个简单的例子来解释这一点。假设项目中的其他人正在处理用户界面，而你正在编写文档。如果没有rebase，你的历史可能看起来像这样:

Write tutorial
Merge remote-tracking branch 'origin/master' into fixdocs
Bigger buttons
Drop down list
Extend README
Merge remote-tracking branch 'origin/master' into fixdocs
Make window larger
Fix a mistake in howto.md

也就是说，合并和UI在文档提交的中间提交。

如果你将你的代码重新基于master而不是合并它，它会像这样:

Write tutorial
Extend README
Fix a mistake in howto.md
Bigger buttons
Drop down list
Make window larger

你所有的提交都在顶部(最新的)，后面跟着主分支的其他部分。

(免责声明:我是另一个答案中提到的“我讨厌Git的10件事”帖子的作者)

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

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