git合并和git rebase有什么区别？

Question

什么是区别之间的git合并和git rebase？

Answer 1

虽然公认的和最受欢迎的答案是伟大的，我还发现试图用语言来解释区别是有用的：

合并

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

重基

• 将主分支（无论其名称如何）的更改提供给我的功能分支。通过假装我的功能工作在以后开始，实际上是在主分支的当前状态下进行的，来实现此操作
• “重写我的更改历史以反映这一点。”（需要强制推送它们，因为通常版本控制都是为了不篡改给定的历史）
• “很可能——如果我所做的更改与我的工作没有多大关系——如果我逐一查看我的提交差异（您可能还会想到“补丁”），历史实际上不会有多大变化。”

小结：如果可能的话，重基几乎总是更好的。使重新集成到主分支中变得更容易。

因为➝ 您的特性工作可以作为一个大的“补丁文件”（aka diff）呈现在主分支上，而不必“解释”多个父级：至少两个来自一个合并，但如果有多个合并，则可能更多。与合并不同的是，多个回扣不会相加。（另一大优势）

Answer 2

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

用语言来解释：

• 当你将你的分支重新建立在他们的分支上时，你告诉Git让它看起来像你干净地检查了他们的分支，然后从那里开始做你所有的工作。这就形成了一个干净的、概念简单的变更包，人们可以查看。当他们的分支上有新的变化时，你可以再次重复这个过程，你总是会在他们分支的“尖端”得到一套干净的变化。
• 当你将他们的分支合并到你的分支时，你在这一点上将两个分支历史联系在一起。如果你以后再做更多的改变，你就开始创建一个交错的历史线索：他们的一些改变，我的一些改变，他们的一些改变。有些人觉得这很乱或不可取。

出于我不理解的原因，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

所有的提交都在顶部（最新的），然后是master分支的其余部分。

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

Answer 3

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

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

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

合并：

提交D和E仍在这里，但我们创建了合并提交M，它继承了D和E的更改。然而，这创造了钻石形状，这让很多人感到非常困惑。

重新基准：

我们创建commitR，它的实际文件内容与上面的merge-commitM相同。但是，我们去掉了commitE，就像它不存在一样（用点-消失线表示）。由于这种删除，E应该是开发人员本地的，并且不应该被推送到任何其他存储库。rebase的优点是避免了钻石形状，历史保持直线——大多数开发人员都喜欢这一点！