在Git中保存线性历史有什么好处？

当我被教导使用Git和central repo（Gitorious上的项目）时，我被告知总是使用rebase而不是merge，因为我们想要线性历史。所以我一直都在努力这样做

现在当我开始思考它时，它真的如此有益吗？重定具有多个提交的分支的基址比简单合并要耗时得多

我现在想到了两个好处：

git对分

有可能与历史一起提交给另一个版本控制系统，如SVN

还有其他好处吗？

线性Git历史（最好包括）有很多优点。除了前面提到的两件事外，还有以下价值：

子孙后代的文档。线性历史通常更容易理解。这与您希望代码具有良好的结构化和文档化的方式类似：无论何时，只要有人以后需要处理它（代码或历史记录），能够快速理解正在发生的事情都是非常有价值的

提高代码审查的效率和有效性。如果一个主题分支被划分为线性的、逻辑的步骤，那么审查它要比审查一个复杂的历史或一个被压扁的变更整体（这可能是压倒性的）容易得多

当您以后需要修改历史记录时。例如，当恢复或拾取全部或部分特征时

可扩展性。除非您在团队规模扩大（例如数百名贡献者）时努力保持历史记录的线性，否则跨分支合并可能会使您的历史记录变得非常臃肿，而且所有贡献者都很难跟踪正在发生的事情

---

一般来说，我认为你的病史越不线性，它的价值就越低。

就我而言，保持线性病史主要是为哮喘患者提供的。对于一个技术娴熟、纪律严明的开发人员来说，这是一个很好的方法来整理历史并使其易于浏览。在一个完美的世界里，我们应该有一个完美的线性历史，让一切都清晰明了

然而，在企业环境中的大型团队中，我通常不建议人为地保留线性历史记录。在一个由精明、经验丰富、纪律严明的开发人员组成的团队中保持历史的直线性是一个好主意，但我经常认为这是一种“最佳实践”或某种“必须做的”。我不同意这样的观点，因为这个世界并不完美，保持一段线性历史要付出很多代价，而人们并没有做好披露工作。以下是项目清单概述：

• 重写历史可以包括删除历史
• 甚至不是每个人都能重新设定基准
• 好处往往被夸大了

现在，让我们深入研究一下警告：长篇大论、趣闻轶事，大多是咆哮

重写历史可以包括删除历史 这里有一个问题，重新调整你所有的承诺，以保持一切美好和线性：重新调整通常不是损失少。有一些信息——开发人员所做的真实、真实的事情——在重新设置基础时可能会从您的历史记录中压缩出来。有时候，这是件好事。如果开发人员发现了他们自己的错误，那么他们最好做一个交互式的重基来整理这些错误。已发现和修复的错误已经得到处理：我们不需要这些错误的历史记录。但有些人和那个似乎总是把冲突搞砸的人一起工作。我个人不认识任何一个叫Neal的开发者，所以假设是一个叫Neal的人。Neal正在一个功能分支上编写一些非常棘手的应收账款代码。Neal在其分支上编写的代码是100%正确的，并且完全按照我们希望的方式工作。Neal将他的代码准备好合并到master中，却发现现在存在合并冲突。如果Neal将master合并到他的feature分支中，我们就有了他的代码最初的历史，以及解决合并冲突后他的代码的样子。如果Neal做了一个重基，我们只在重基后有他的代码。如果Neal在解决合并冲突时出错，那么前者的故障排除将比后者容易得多。但更糟糕的是，如果Neal以一种非常不幸的方式破坏了他的rebase（也许他进行了git签出——我们的，但他忘了在那个文件中有重要的更改），我们可能会永远丢失他的部分代码

我明白了，我明白了。他的单元测试应该发现了这个错误。代码审阅者应该已经发现了错误。QA应该发现这个错误。他本来不应该把解决合并冲突搞砸的。废话，废话，不在乎。Neal退休了，首席财务官很生气，因为我们的账本都搞砸了，告诉首席财务官“根据我们的发展理念，这不应该发生”会让我脸上挨一拳

兄弟，不是每个人都能重新设定基准。是的，我听说过：你在某个太空时代的初创公司工作，你的物联网咖啡桌只使用最酷、最现代、反应性最强、基于区块链的递归神经网络，而技术堆栈是病态的！Go发明时，你的首席开发人员就在那里，在那里工作的每个人从11岁起就都有Linux内核贡献者。我很想听到更多，但我只是没有时间了解有多少人问我“如何退出git diff？”。每次有人试图重新设置基址以解决他们与master的冲突时，我都会被问到“为什么它说我的文件是他们的文件”，或者“为什么我只看到部分更改”，然而大多数开发人员可以处理将master合并到他们的分支中而不会发生意外。也许情况不应该如此，但事实确实如此。当你有初级开发人员和实习生，忙碌的人，还有那些直到成为pr才知道源代码管理是什么的人