Pro Git的书在重新设置基础页面上有一个很好的解释。

基本上，合并将进行两次提交并合并它们。

一个重基将转到这两者的共同祖先，并在彼此之上逐步应用更改。这使得历史更加“清晰”和线性。

但当您重新创建基准时，您将放弃以前的提交并创建新的提交。因此，您永远不应该重新设置公共存储库的基础。其他在存储库中工作的人会恨你。

仅出于这个原因，我几乎完全合并了。99%的时候，我的分支机构没有太大的差异，所以如果有冲突，只会发生在一两个地方。

在合并/重新基础之前：

A <- B <- C    [master]
^
 \
  D <- E       [branch]

git合并主机后：

A <- B <- C
^         ^
 \         \
  D <- E <- F

git rebase master之后：

A <- B <- C <- D' <- E'

（A、B、C、D、E和F为提交）

在Git基础教程中可以找到这个例子以及更多关于Git的详细信息。

为了补充TSamper提到的我自己的答案，

在合并之前，重新创建数据库通常是一个好主意，因为这样做的目的是在分支Y中集成将要合并的分支B的工作。但同样，在合并之前，您要解决分支中的任何冲突（即：“rebase”，如“从分支B的最近一点开始在分支中回放我的工作”）。如果操作正确，后续从分支到分支B的合并可以快速进行。合并直接影响目标分支B，这意味着合并最好是微不足道的，否则分支B可能很长时间才能恢复到稳定状态（是时候解决所有冲突了）

重新基础后合并的意义？

在我描述的情况下，我将B重新放在我的分支上，只是为了有机会从B的最近一点回放我的工作，但同时留在我的分支。在这种情况下，仍然需要合并才能将我的“回放”工作带到B上。

另一种场景（例如Git Ready中描述的）是通过重基（rebase）将您的工作直接带到B中（这会保留所有漂亮的提交，甚至会给您机会通过交互式重基重新排序）。在这种情况下（当您在B分支中时重新创建基础），您是正确的：不需要进一步合并：

当我们没有合并或重新基础时，默认情况下是Git树

我们通过重新定基获得：

第二个场景的全部内容是：我如何将新功能恢复到主功能。

通过描述第一个重基场景，我的目的是提醒大家，重基也可以作为实现这一目标的初步步骤（即“将新功能重新引入主功能”）。您可以使用rebase首先将master“带入”新特性分支：rebase将重放来自HEAD master的新特性提交，但仍在新特性分支中，有效地将分支起点从旧的master提交移动到HEAD master。这允许您解决分支中的任何冲突（即，隔离，同时如果冲突解决阶段花费太长时间，则允许主分支继续并行发展）。然后，您可以切换到主功能并合并新功能（如果您想保留在新功能分支中完成的提交，则可以将新功能重新放到主功能上）。

So:

“rebase与merge”可以被视为两种方法来导入一个工作，例如master。但“先重新创建基础，然后合并”可以是一个有效的工作流，它可以先孤立地解决冲突，然后再恢复工作。

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

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

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

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

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

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

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

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

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

TLDR：这取决于什么是最重要的——整洁的历史还是发展顺序的真实再现

如果一个整洁的历史是最重要的，那么你会先重新基址，然后合并你的更改，所以很清楚新代码是什么。如果你已经推送了你的分支，除非你能够处理后果，否则不要重新基址。

如果序列的真实表示是最重要的，那么您可以合并而不重定基础。

合并意味着：创建一个新的提交，将我的更改合并到目标中。注意：这个新的提交将有两个父级：一个是提交字符串中的最新提交，另一个是合并的另一个分支的最新的提交。

Rebase的意思是：使用我当前的一组提交作为提示，创建一系列新的提交。换言之，计算一下如果我从重新基准点开始进行更改，我的更改会是什么样子。因此，在重新基准之后，您可能需要重新测试您的更改，并且在重新基准期间，您可能会发生一些冲突。

既然如此，你为什么要重新基准？只是为了保持发展历史的清晰。假设您正在处理功能X，当您完成后，将您的更改合并到中。目标现在将有一个单独的提交，该提交内容类似于“添加的功能X”。现在，如果您重新创建基础，然后进行合并，那么目标开发历史将包含单个逻辑进程中的所有单独提交，而不是合并。这使得以后查看更改更加容易。想象一下，如果50名开发人员一直在合并各种功能，那么你会发现很难回顾开发历史。

也就是说，如果您已经将正在处理的分支推到了上游，那么不应该重新创建基础，而应该合并。对于尚未向上游推送的分支，请重新基址、测试和合并。

另一次您可能需要重新设置基值，是在向上游推送之前从分支中删除提交。例如：早期引入一些调试代码的提交和进一步清理代码的提交。实现这一点的唯一方法是执行交互式rebase:gitrebase-i<branch/commit/tag>

更新：当您使用Git连接到不支持非线性历史的版本控制系统（例如Subversion）时，还需要使用rebase。在使用git-svn桥时，非常重要的是，您合并回Subversion的更改是主干中最新更改之上的一系列更改。只有两种方法可以做到这一点：（1）手动重新创建更改；（2）使用rebase命令，这要快得多。

更新2：另一种考虑rebase的方法是，它可以从您的开发风格映射到您提交的存储库中接受的风格。你有一次提交来修复拼写错误，一次提交去清除未使用的代码等等。当你完成你需要做的事情时，你有一系列的提交。现在让我们假设您提交的存储库鼓励大量提交，因此对于您正在进行的工作，可能需要一次或两次提交。如何获取提交字符串并将其压缩到预期值？你可以使用一个交互式的rebase，将你的小提交压缩成更少的大块。如果需要相反的方式，情况也是如此——如果您的风格是几个大的提交，但存储库需要长串的小提交。你也可以使用rebase来实现这一点。如果您进行了合并，那么现在已经将提交样式移植到了主存储库中。如果有很多开发人员，你可以想象一段时间后，用几种不同的提交样式来跟踪历史会有多困难。

更新3：成功重新创建数据库后，是否仍需要合并？是的，你是这样做的。原因是重基基本上涉及到提交的“转移”。如上所述，这些提交是经过计算的，但如果从分支点开始有14个提交，那么假设您的重基没有任何问题，那么在重基完成后，您将提前14个提交（在您重基的点之前）。你在重新开始之前有一个分支。之后将有一个相同长度的分支。您仍然需要在发布更改之前进行合并。换言之，尽可能多次地重新设置基准（同样，只有在您没有将更改推到上游的情况下）。仅在重新基准后合并。

一些与Gerrit用于审查和交付集成的大规模开发相关的实际示例：

当我将我的功能分支提升到一个新的远程主机时，我就合并了。这提供了最小的提升工作，并且很容易跟踪功能开发的历史，例如gitk。

git fetch
git checkout origin/my_feature
git merge origin/master
git commit
git push origin HEAD:refs/for/my_feature

我在准备交付提交时合并。

git fetch
git checkout origin/master
git merge --squash origin/my_feature
git commit
git push origin HEAD:refs/for/master

无论什么原因，当我的交付提交未能集成时，我都会重新启动，我需要将其更新为新的远程主机。

git fetch
git fetch <gerrit link>
git checkout FETCH_HEAD
git rebase origin/master
git push origin HEAD:refs/for/master