git merge 和 git rebase 有什么区别？
【问题讨论】：
标签： git merge git-merge rebase git-rebase
merge 和 rebase 有什么区别？阅读官方 Git 手册，它指出 “rebase 在另一个基础分支上重新应用提交”，而 “merge 将两个或多个开发历史连接在一起”。换句话说，merge 和 rebase 之间的主要区别在于，merge 保留发生的历史，rebase 重写它。
让我们用一个并排的例子来说明这些陈述的背景！
如上图所示，merge 操作通过创建一个新的单一合并提交 (C7) 将分支交织在一起，从而导致菱形非线性历史 - 基本上保留了发生的历史。通过将此结果与 rebase 操作的结果进行比较，我们看到没有创建合并提交，而是两个提交 C5 和 C6 只是被倒带并直接重新应用C4 的顶部，保持历史线性。
如果我们进一步检查这两个重新应用的提交，我们可以看到哈希值发生了变化，这表明 rebase 确实重写了历史记录。
每当你rebase 一个分支时，新的提交总是会生成，即使内容可能仍然相同！也就是说，如果没有其他指针（分支/标签）引用它们，任何以前的提交最终都会（垃圾回收后）从历史记录中删除。
我们已经看到 rebase 如何重写历史，而 merge 保留它。但这在更广泛的意义上意味着什么？这两种操作会带来哪些可能性和潜在的弊端？
冲突的更改
例如，假设您在尝试整合更改时遇到了一些令人讨厌的冲突。在合并场景中，您只需要直接在 C7 提交中解决冲突一次。另一方面，使用 rebase 时，您可能不得不在每次提交（C5 和 C6）中解决类似的冲突，因为它们被重新应用。
已发布的分支
另一个与 rebase 相关的潜在问题发生在您正在 rebase 的分支已经远程发布，并且其他人已经基于它进行了工作。然后，您的重新定位分支可能会给所有相关方造成严重的混乱和头痛，因为 Git 会告诉您您的分支同时领先和落后。如果发生这种情况，使用 rebase 标志 (git pull --rebase) 拉取远程更改通常可以解决问题。
此外，每当您对已发布的分支进行变基时，无论其他人是否基于其工作，您仍然需要强制推送它以获取远程服务器的更新 — 完全覆盖现有的远程引用.
数据丢失（对您有利）
最后，由于 rebase 会重写历史，而 merge 会保留它，因此在 rebase 时实际上可能会丢失数据。当重新应用新的提交时，旧的提交（最终在垃圾回收后）被删除。实际上，正是这一特性使 rebase 如此强大——它允许您在公开之前整理您的开发历史！
虽然从潜在数据丢失的角度来看，merge 可以安全使用，并且使用起来感觉更直接。以下是一些可以帮助您避免与rebase 相关的最常见问题的提示。
来源：以上摘录摘自这篇关于该主题的完整帖子：Differences Between Git Merge and Rebase — and Why You Should Care
【讨论】：
我发现一篇关于 git rebase vs merge 的非常有趣的文章，想分享一下here
【讨论】：
Git rebase 更接近于合并。 rebase 的区别在于：
这意味着在所有远程提交之后，您的所有本地提交都会移到最后。如果你有合并冲突，你也必须解决它。
【讨论】：
虽然被接受且最受好评的答案很棒，但我还发现尝试仅用文字来解释差异很有用：
合并
变基
总结：如果可能，rebase 几乎总是更好。使重新集成到主分支更容易。
因为？ ➝ 您的功能工作可以呈现为 一个 相对于主分支的大“补丁文件”（又名 diff），而不必“解释”多个父级：至少两个，来自一个合并，但可能更多，如果有几个合并。 与合并不同，多个变基不会累加。（另一个大优点）
【讨论】：
就我个人而言，我不认为标准的图表技术很有帮助 - 箭头似乎总是指向错误的方向。 （它们通常指向每个提交的“父”，最终会在时间上倒退，这很奇怪）。
用文字来解释：
由于我不明白的原因，Git 的 GUI 工具从未付出太多努力来更清晰地呈现合并历史，抽象出单个合并。所以如果你想要一个“干净的历史”，你需要使用 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 件事”帖子的作者）
【讨论】：
假设最初有 3 个提交，A,B,C:
然后开发者 Dan 创建了提交 D，开发者 Ed 创建了提交 E：
显然，这种冲突应该以某种方式解决。为此，有两种方法：
合并：
D 和 E 仍然存在，但我们创建了合并提交 M，它继承了 D 和 E 的更改。但是，这会产生 菱形 形状，许多人对此感到非常困惑。
REBASE：
我们创建commit R，其实际文件内容与上面的merge commit M相同。但是，我们摆脱了提交E，就像它从未存在过一样（用点表示 - 消失线）。由于这种删除，E 应该是开发人员 Ed 本地的，并且不应该被推送到任何其他存储库。 rebase 的优点是避免了 diamond 形状，并且历史保持良好的直线 - 大多数开发人员都喜欢它！
【讨论】：
git merge 不会交错提交（但通过查看 git log 可能会出现这种情况）。取而代之的是，git merge 保留了 Dan 和 Ed 的开发历史原封不动地保存下来，就像一次从每个角度看到的那样。 git rebase 看起来是 Dan 先做的，Ed 跟着他。在这两种情况下（合并和变基），实际生成的文件树是完全相同的。