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

Question

当我使用带有中央仓库的git(Gitorious项目)教我时,我被告知总是使用rebase而不是merge,因为我们想要有线性历史.所以我一直都在努力工作.

现在,当我开始思考它是否真的如此有益？具有许多提交的重新分支比简单合并更耗时.

现在我想到了两个优点:

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

还有其他好处吗？

Answer 1

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

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

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

Answer 2

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

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

• 重写历史可以包括擦除历史
• 并不是每个人都可以改头换面
• 好处常常被夸大了

现在，让我们深入探讨。

重写历史记录可以包括擦除历史记录 这是重新整理所有提交以保持所有内容的美观和线性的问题：重新整理通常并非没有损失。开发人员完成了真实的，实际的信息，这些信息可能会在您重新设置基准时从您的历史记录中压缩掉。有时候，那是一件好事。如果开发人员发现了自己的错误，那么对他们来说，进行交互式的基准调整以解决问题是很好的。固定错误已得到处理：我们不需要它们的历史记录。但是有些人与那个似乎总是加紧合并冲突的人一起工作。我个人不认识任何名为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; 我并不是说变基和线性历史记录都不好。我只是说，您需要了解您要注册的内容，并就是否适合您的团队做出明智的决定。完全线性的历史记录不是必需的，而且当然不是免费的。在适当的情况下，它绝对可以使生活变得更美好，但对每个人来说都没有意义。

Answer 3

如果您经常对您的工作进行变基，并且没有其他人在处理您的代码的该部分，那么它通常应该是一个无关紧要的事件。

这些命令或多或少（来自）：

git checkout -b my-new-feature
git push -u origin my-new-feature

# Changes and commits

git rebase origin/master
git push origin my-new-feature --force-with-lease
git merge --no-ff my-new-feature

这里的人们似乎也误解了合并和合并提交。我赞成使用合并提交的线性历史记录，就像这样。这样，如果需要，您可以看到各个提交，但也可以从一个合并跳转到另一个合并。

Answer 4

以下是合并时变基或压缩提交的赞成/反对列表。

专业人士：

• 易于阅读按时间顺序排列的历史
• 历史上没有无关的提交
• 将分支/PR 拆分为更小的块以便于审查，并且无需合并提交即可更轻松地进行测试
• 能够轻松地对功能分支进行变基（FX.以更改合并顺序）
• 它鼓励有意义的提交消息（但不强制执行）
• 在进行发布时，人们可以更轻松地查看历史记录并用它来编写更改日志，以供测试人员、消费者等使用。
• 通过提交变基的提交鼓励 PR 进行更少/更小的提交

缺点：

• 比较复杂，有经验的人较少
• 如果不小心在远程分支上使用，可能会导致问题。示例，丢失的提交，本地环境中不一致的历史记录
• 这是一个额外需要维护的东西（x 项目真的需要这个吗？）
• 如果您对具有许多冲突提交的分支进行变基，则会耗费更多时间

个人笔记

我也提到了合并之前的压缩，因为它在历史方面具有类似的效果。

此外，大多数 github 和其他服务都在 GUI 中提供了重新合并和压缩合并的选项。

在某些情况下，这实际上是公关人员的自由行动。