git rebase 丢失历史，那为什么要 rebase？

Question

在过去的几天里，我一直在研究使用 Git 进行 rebase 。大多数支持 rebase 的论点都说它清理了历史并使其更加线性。如果你进行普通 merge (例如)，你会得到一个历史记录，显示历史记录何时分开以及何时重新组合在一起。据我所知， rebase 删除了所有这些历史记录。问题是:您为什么不希望 repo 历史反射(reflect)代码开发的所有方式，包括它在哪里以及如何发散？

Answer 1

假设您正在从事一项统治世界的 secret 项目。这场阴谋的主谋一共有三位:

• 天才
• 将军
• 电脑黑客

他们都同意在 1 周内来到他们的 secret 基地，每个人都有 1 个详细计划。

计算机黑客，作为一个务实的程序员，建议他们使用Git来存储计划的所有文件。每个人都会 fork 最初的项目 repo ，他们将在一周内 merge 所有内容。

他们都同意，在接下来的几天里，故事是这样的:

天才

他总共进行了 70 次提交，每天 10 次。

将军

他监视了他们同志的 repo 并制定了击败他们的策略。他在最后一天做了 3 次提交。

电脑黑客

这位务实的程序员使用了分支。他制定了 4 个不同的计划，每个计划都在一个分支上。每个分支都重新设置为仅一次提交。

7 天过去了，小组再次开会，将所有计划 merge 为一个杰作。他们都急于开始，所以他们都试图自己 merge 所有的东西。

故事是这样的:

天才

他 merge 了将军的仓库中的所有更改，然后 merge 了计算机黑客的仓库中的所有更改。然后，作为一个逻辑爱好者，他看了看日志。他希望看到一个想法的逻辑演化，其中事物是根据以前的想法构建的。

但是日志显示的是时间线中混合了无数不同想法的提交。仅通过阅读提交时间线，一位读者无法真正理解演变和提交的推理。

所以他的结局一塌糊涂，连天才都看不懂。

将军

一般思想:分而治之!

因此他将 Genius 的仓库 merge 到他的仓库中。他查看了日志，看到了 Genius idea 的一堆提交，这些提交遵循不稳定的进展，直到最后一天。最后一天，将军和天才的想法是混合的。

他正在监视 The computer Hacker 并且知道 Rebase 解决方案。所以他根据自己的想法做了一个rebase，然后再次尝试 merge 。

现在日志每天都按逻辑顺序显示。

电脑黑客

这位务实的程序员为 Genius idea 创建了一个集成分支，另一个为 General idea，另一个为他自己的想法。他对每个分支都进行了调整。然后他将所有内容 merge 到 master 中。

他的所有队友都看到他的日志很棒。这很简单。乍一看还不太稳定。

如果一个想法引入了一个问题，那么很清楚引入了哪个提交，因为只有一个。

他们结束了对整个世界的征服，他们不再使用 Subversion。

大家都很开心。