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

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

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

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

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

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

走

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

变基

“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不能叠加。(另一个大优点)

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

用语言解释一下:

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件事”帖子的作者)

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

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

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

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

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

走：

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

变基:

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