在git中保留线性历史有什么好处

就我而言，保持线性历史主要是为了美学。对于熟练，训练有素的开发人员而言，这是整理历史记录并使其轻松浏览的一种很好的方法。在一个完美的世界中，我们应该拥有一个完美的线性历史，使一切都变得清晰。

但是，在企业环境中的大型团队中，我通常不建议人为地保持线性历史记录。在一支由经验丰富，纪律严明的开发人员组成的团队中保持线性关系是一个不错的主意，但我经常将其规定为“最佳实践”或某种“必须做的事情”。我不同意这样的观点，因为世界并不完美，而且保持线性历史记录会花费很多成本，因为人们没有做好公开的工作。这是项目符号列表概述：

重写历史可以包括擦除历史

并不是每个人都可以改头换面

好处常常被夸大了

现在，让我们深入探讨。

重写历史记录可以包括擦除历史记录 这是重新整理所有提交以保持所有内容的美观和线性的问题：重新整理通常并非没有损失。开发人员完成了真实的，实际的信息，这些信息可能会在您重新设置基准时从您的历史记录中压缩掉。有时候，那是一件好事。如果开发人员发现了自己的错误，那么对他们来说，进行交互式的基准调整以解决问题是很好的。固定错误已得到处理：我们不需要它们的历史记录。但是有些人与那个似乎总是加紧合并冲突的人一起工作。我个人不认识任何名为Neal的开发人员，所以可以说它是一个叫Neal的人。Neal正在功能分支上处理一些非常棘手的应收帐款代码。Neal在其分支上编写的代码是100％正确的，并且完全按照我们希望的方式工作。尼尔准备好将他的代码全部合并到master中，却发现现在存在合并冲突。如果Neal将master合并到他的功能分支中，那么我们将拥有他的代码最初的历史以及解决合并冲突后他的代码的历史。如果Neal进行了变基，那么在变基之后我们只有他的代码。如果Neal在解决合并冲突时犯了一个错误，则对前者进行故障诊断要比对后者进行故障诊断容易得多。但是更糟糕的是，如果尼尔以一种非常不幸的方式破坏了他的基础（也许他做了git checkout-我们，但他忘记了他对该文件的重要更改），我们可能会永远丢失他的部分代码。对前者进行故障诊断要比对后者进行故障诊断容易得多。但是更糟糕的是，如果尼尔以一种非常不幸的方式破坏了他的基础（也许他做了git checkout-我们，但他忘记了他对该文件的重要更改），我们可能会永远丢失他的部分代码。对前者进行故障诊断要比对后者进行故障诊断容易得多。但是更糟糕的是，如果尼尔以一种非常不幸的方式破坏了他的基础（也许他做了git checkout-我们，但他忘记了他对该文件的重要更改），我们可能会永远丢失他的部分代码。

我明白了，我明白了。他的单元测试应该已经发现了错误。代码检查者应该已经发现了错误。质量检查人员应该已经发现了错误。首先，他不应该搞砸解决合并冲突。ah，don，不在乎。尼尔退休了，首席财务官很生气，因为我们的账本全都搞砸了，告诉首席财务官“根据我们的发展哲学，这本不应该发生的”会让我大吃一惊。

兄弟，不是每个人都可以改头换面。是的，我听说：您在某个太空时代的初创公司工作，并且您的物联网咖啡桌仅使用最酷，最现代的，基于反应性，基于区块链的循环神经网络，并且技术堆栈令人生病！您的首席开发人员确实在那里当Go被发明时，每个工作的人都从11岁起就开始有Linux内核贡献者。我很想听听更多，但是我只是没有时间问我'我如何退出git diff ???'。每当有人尝试重新建立基础以解决与master的冲突时，我都会被问到“为什么说我的文件是他们的文件”或“为什么我只看到更改的一部分”，但是大多数开发人员仍可以将master合并到他们的分支没有事故。也许不应该这样，但是确实如此。当您有初级开发人员和实习生，忙碌的人们以及直到在您的团队中已经担任程序员35年之后才发现源代码控制的人员时，要保持原始状态就需要大量工作。

好处常常被夸大了。我们都在您从事的那个项目上git log --graph --pretty，突然您的终端被彩虹意大利面接管了。但是历史并不难读，因为它是非线性的。它很难读，因为它草率。一个草率的线性历史记录，其中每个提交消息都是“。”。与具有周到的提交消息的相对干净的非线性历史记录相比，它不会更容易阅读。拥有非线性历史记录并不意味着您必须先使分支之间来回合并几次，然后才能到达母版。这并不意味着您的分支机构必须生存6个月。历史记录图表上的偶然分支不是世界末日。

我也不认为使用git bisect对非线性历史记录没有那么困难。熟练的开发人员应该能够想到很多方法来完成工作。这是我喜欢的一篇文章，上面举了一个很好的例子说明了一种实现方法。 https://blog.smart.ly/2015/02/03/git-bisect-debugging-with-feature-branches/

tldr; 我并不是说变基和线性历史记录都不好。我只是说，您需要了解您要注册的内容，并就是否适合您的团队做出明智的决定。完全线性的历史记录不是必需的，而且当然不是免费的。在适当的情况下，它绝对可以使生活变得更美好，但对每个人来说都没有意义。

线性Git历史(优选地由逻辑步骤组成)具有许多优点.除了已经提到的两件事之外,还有以下价值:

后人的文件.线性历史通常更容易遵循.这与您希望代码的结构和记录方式类似:只要有人需要稍后处理它(代码或历史记录),能够快速了解​​正在发生的事情是非常有价值的.

提高代码审查的效率和有效性.如果将主题分支划分为线性,逻辑步骤,则与查看复杂的历史记录或压缩的变更整体(这可能是压倒性的)相比,查看它更容易.

当您需要稍后修改历史记录时.例如,当全部或部分地恢复或挑选特征时.

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

总的来说,我认为历史越不线性,它的价值就越小.