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

用语言解释一下:

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

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

用语言解释一下:

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次提交

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

走

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

变基

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

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

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

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

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

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