这里的很多答案都说，合并会将所有提交转换为一个，因此建议使用rebase来保存提交。这是不正确的。如果你已经提交了，那是个坏主意。

合并不会消除提交。合并保留历史！（看看gitk）热巴改写了历史，这是你推后的坏事。

使用merge，而不是在已经推送的情况下重新设置基址。

这是Linus（Git的作者）对它的看法（现在托管在我自己的博客上，由Wayback Machine恢复）。这真是一本好书。

或者你可以在下面阅读我自己的版本。

在主节点上重新分配分支：

提供了如何创建提交的错误想法用一堆可能没有经过良好测试的中间提交来污染master实际上可能会在这些中间提交上引入构建中断，因为在创建原始主题分支和重新创建主题分支之间对master进行了更改。这使得在master中找到好地方结账变得困难。导致提交的时间戳与其在树中的时间顺序不一致。因此，您将看到提交A在主提交B之前，但提交B是先编写的。（什么？！）产生更多的冲突，因为主题分支中的每个提交都可能涉及合并冲突，这些冲突必须单独解决（关于每个提交中发生的情况，请进一步查看历史）。是对历史的改写。如果正在重新创建的分支被推到任何地方（与除您之外的任何人共享），那么自您改写历史以来，您已经将拥有该分支的所有其他人都搞砸了。

相反，将主题分支合并为主分支：

保留主题分支创建位置的历史记录，包括从主分支到主题分支的任何合并，以帮助保持其最新状态。您可以准确地了解开发人员在构建时使用的代码。master是一个主要由合并组成的分支，而这些合并提交中的每一个都是历史上可以安全检出的“好点”，因为这就是主题分支可以集成的地方。主题分支的所有单独提交都会被保留，包括它们位于主题分支中的事实，因此隔离这些更改是很自然的，您可以在需要时钻取。合并冲突只需解决一次（在合并时），因此在主题分支中进行的中间提交更改不必单独解决。可以平滑地进行多次。如果您定期将主题分支集成到master，人们可以继续在主题分支上进行构建，并且可以继续独立地进行合并。

当您正在处理分支并在其间合并了一些其他工作时，Rebase是有用的-合并将创建更改，从而使diff受到污染，因此更难阅读。

如果您重新设置分支的基值，那么您的提交将应用于要重新设置基值的分支的顶部，这使得查看更容易，并且diff输出更干净。

这里的很多答案都说，合并会将所有提交转换为一个，因此建议使用rebase来保存提交。这是不正确的。如果你已经提交了，那是个坏主意。

合并不会消除提交。合并保留历史！（看看gitk）热巴改写了历史，这是你推后的坏事。

使用merge，而不是在已经推送的情况下重新设置基址。

这是Linus（Git的作者）对它的看法（现在托管在我自己的博客上，由Wayback Machine恢复）。这真是一本好书。

或者你可以在下面阅读我自己的版本。

在主节点上重新分配分支：

提供了如何创建提交的错误想法用一堆可能没有经过良好测试的中间提交来污染master实际上可能会在这些中间提交上引入构建中断，因为在创建原始主题分支和重新创建主题分支之间对master进行了更改。这使得在master中找到好地方结账变得困难。导致提交的时间戳与其在树中的时间顺序不一致。因此，您将看到提交A在主提交B之前，但提交B是先编写的。（什么？！）产生更多的冲突，因为主题分支中的每个提交都可能涉及合并冲突，这些冲突必须单独解决（关于每个提交中发生的情况，请进一步查看历史）。是对历史的改写。如果正在重新创建的分支被推到任何地方（与除您之外的任何人共享），那么自您改写历史以来，您已经将拥有该分支的所有其他人都搞砸了。

相反，将主题分支合并为主分支：

保留主题分支创建位置的历史记录，包括从主分支到主题分支的任何合并，以帮助保持其最新状态。您可以准确地了解开发人员在构建时使用的代码。master是一个主要由合并组成的分支，而这些合并提交中的每一个都是历史上可以安全检出的“好点”，因为这就是主题分支可以集成的地方。主题分支的所有单独提交都会被保留，包括它们位于主题分支中的事实，因此隔离这些更改是很自然的，您可以在需要时钻取。合并冲突只需解决一次（在合并时），因此在主题分支中进行的中间提交更改不必单独解决。可以平滑地进行多次。如果您定期将主题分支集成到master，人们可以继续在主题分支上进行构建，并且可以继续独立地进行合并。

简短版本

合并在一个分支中接受所有更改，并在一次提交中将它们合并到另一个分支。Rebase说我希望我的分支点转移到一个新的起点

那你什么时候用这两种？

合并

假设您创建了一个分支来开发单个功能。当您想将这些更改带回master时，可能需要合并。

回扣

第二种情况是，如果您开始进行一些开发，然后另一个开发人员进行了不相关的更改。您可能希望从存储库中提取并重新创建基础，以将当前版本的更改作为基础。

挤压：在这两种情况下都会保留所有提交（例如：“add feature”，然后是“typ”，然后“oops typ again”…）。通过挤压，可以将提交合并为单个提交。挤压可以作为合并或重基操作（--squash标志）的一部分完成，在这种情况下，通常称为挤压合并或挤压重基。

拉取请求：流行的git服务器（Bitbucket、GitLab、GitHub等）允许配置如何在每个回购基础上合并拉取请求。按照惯例，UI可能会显示“合并”按钮，但该按钮可以使用任何标志（关键字：合并、重基、挤压、快进）执行任何操作。

虽然合并绝对是集成更改的最简单和最常见的方式，但它不是唯一的方式：Rebase是一种替代的集成方式。

更好地理解合并

当Git执行合并时，它会查找三个提交：

（1） 共同祖先提交。如果您遵循一个项目中两个分支的历史，它们总是至少有一个共同的提交：此时，两个分支都具有相同的内容，然后演变不同。（2） +（3）每个分支的端点。集成的目标是合并两个分支的当前状态。因此，它们各自的最新修订值得特别关注。将这三个提交结合起来，将实现我们的目标。

快进或合并提交

在非常简单的情况下，两个分支中的一个分支自分支发生以来没有任何新的提交——其最新的提交仍然是共同的祖先。

在这种情况下，执行集成非常简单：Git只需将其他分支的所有提交添加到共同祖先提交之上即可。在Git中，这种最简单的集成形式被称为“快进”合并。然后，两个分支共享完全相同的历史。

然而，在很多情况下，这两个分支都各自向前移动。

为了进行集成，Git必须创建一个包含它们之间差异的新提交，即合并提交。

人工提交和合并提交

通常，一个承诺是由一个人精心创造的。这是一个有意义的单元，它只包装相关的更改并用注释注释它们。

合并提交有点不同：它不是由开发人员创建的，而是由Git自动创建的。而不是包装一组相关的更改，其目的是连接两个分支，就像一个结一样。如果以后想了解合并操作，需要查看两个分支的历史记录和相应的提交图。

与Rebase集成

有些人更喜欢不进行这种自动合并提交。相反，他们希望项目的历史看起来像是沿着一条直线发展的。没有迹象表明它在某一时刻被拆分为多个分支。

让我们一步一步地完成一个rebase操作。场景与前面的示例相同：我们希望将分支B的更改集成到分支A中，但现在使用rebase。

我们将分三步完成

git rebase branch-A//将历史与branch-A同步git checkout branch-A//将当前分支更改为branch-Agitmergebranch-B//合并/从branch-B到branch-A进行更改

首先，Git将“撤消”分支A上的所有提交，这些提交发生在行开始分支之后（在共同祖先提交之后）。然而，当然，它不会丢弃它们：相反，您可以将这些提交视为“暂时保存”。

接下来，它应用我们要集成的分支B的提交。此时，两个分支看起来完全相同。

在最后一步中，分支A上的新提交现在被重新应用，但在分支B的集成提交之上的一个新位置上（它们是基于重新的）。

结果似乎是直线发展。与包含所有合并更改的合并提交不同，保留了原始提交结构。

最后，您得到了一个干净的分支分支a，没有不需要的和自动生成的提交。

注：摘自git tower的精彩帖子。在同一篇文章中，rebase的缺点也是一个很好的解读。

信息图形总是有用的：）

合并：将一个分支重叠到另一个分支上

Assume the following history exists and the current branch is "master":

                     A---B---C topic
                    /
               D---E---F---G master

       Then "git merge topic" will replay the changes made on the topic branch since it
       diverged from master (i.e., E) until its current commit (C) on top of master, and
       record the result in a new commit along with the names of the two parent commits
       and a log message from the user describing the changes.

                     A---B---C topic
                    /         \
               D---E---F---G---H master

Rebase：将一个分支的更改移动到另一个分支末端

Assume the following history exists and the current branch is "topic":

                     A---B---C topic
                    /
               D---E---F---G master

       From this point, the result of either of the following commands:

           git rebase master
           git rebase master topic

       would be:

                             A'--B'--C' topic
                            /
               D---E---F---G master

       NOTE: The latter form is just a short-hand of git checkout topic followed by git
       rebase master. When rebase exits topic will remain the checked-out branch.

因此，我们基本上可以得出结论，合并是一个安全的选项，它可以保存存储库的整个历史，而重基化通过将特性分支移动到main的顶端来创建线性历史。

Credit:帮助页面gitmerge--help和gitrebase--help