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

Question

当我使用带有中央回购的git（Gitorious项目）教我时，我被告知总是使用rebase而不是merge，因为我们想要有线性历史。所以我一直都在努力工作。

现在，当我开始思考它是否真的如此有益？使用多次提交重新绑定分支比简单合并更耗时。

现在我想到了两个优势：

1. git bisect
2. 有可能将历史记录提交给另一个版本控制系统，如SVN

还有其他好处吗？

Answer 1

线性Git历史（最好由logical steps组成）具有许多优点。除了已经提到的两件事之外，还有以下价值：

1. 后人的文档。线性历史记录通常更容易理解。这与您希望代码的结构和记录方式类似：只要有人需要稍后处理它（代码或历史记录），能够快速了解​​正在发生的事情是非常有价值的。
2. 提高代码审核的效率和效果。如果将主题分支划分为线性逻辑步骤，则与查看复杂的历史记录或压缩的变更整体相比，查看主题分支要容易得多可能是压倒性的。）
3. 当您需要稍后修改历史记录时。例如，当全部或部分还原或挑选某个功能时。
4. 可伸缩性。除非您努力在团队规模扩大时保持历史线性（例如数百名贡献者），否则您的历史记录会因跨分支合并而变得非常臃肿，并且对所有人来说都很难跟踪正在发生的事情的贡献者。

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

Answer 2

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

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

• 重写历史可以包括擦除历史
• 不是每个人都可以改头换面的，兄弟
• 收益常常被夸大了

现在，让我们深入研究。

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

我明白了，我明白了。他的单元测试应该已经发现了错误。代码检查者应该已经发现了错误。质量检查人员应该已经发现了错误。首先，他不应该搞砸解决合并冲突。 ah，don，不在乎。 Neal退休了，CFO生气了，因为我们的账本全都搞砸了，并告诉CFO“根据我们的发展理念，这 ”已经发生了。

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

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

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

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

Answer 3

使用线性历史记录，您可以使用git log --follow轻松跟踪跨重命名的单个文件的历史记录。引用log.follow config选项上的文档：

  

如果true，git log的行为就像在   给出了。与--follow具有相同的限制，   即它不能用于跟踪多个文件，并且不能很好地工作   在非线性历史上。

Answer 4

这是合并时变基或压缩提交的专业列表。

专业版：

• 易于阅读的历史记录
• 历史上没有多余的提交
• 将分支机构/ PR分成较小的块，以便于查看，并且无需合并提交，测试也更加容易
• 能够轻松对要素分支进行基础调整（按Fx键更改合并顺序）
• 它鼓励有意义的提交消息（但不强制执行）
• 发布时，可以更轻松地查看历史记录并使用它编写变更日志，以供测试人员，消费者等使用。
• 逐个提交重新提交基准可鼓励PR较少/较小的提交

骗局

• 它更加复杂，人们对其使用的经验更少
• 如果不小心在远程分支上使用，可能会导致问题。示例，丢失的提交，本地环境中的历史记录不一致
• 维护是一件额外的事情（x项目真的需要这个吗？）
• 如果使用许多冲突的提交为分支建立基础，则将花费更多时间

个人笔记

我在合并之前也提到过挤压，因为在历史上它具有类似的作用。

此外，大多数github和其他服务都具有在GUI中重新设置基准和合并的选项。

在某些情况下，实际上对PR来说是免费的动作。