为什么我更喜欢常规合并提交而不是压缩提交

为什么我更喜欢常规合并提交而不是压缩提交

我曾经认为 squash commits很酷，然后我不得不整天、每天都使用它们。这就是为什么你应该避免南瓜

image.png

“哇，太酷了！”

日常开发工作中，在整个公司中一致使用 squash commits 是一种“专业精神”和“我们知道我们在这里做什么！”的尖叫声。

但是，平常开发工作中使用的压缩提交，在遇到一个拥有 200 多名成员的大型工程组织时，闲的力不从心。

比较 Squash 与 Merge Git 提交

作为复习，“压缩提交”和“合并提交”之间的区别在于常规“合并”包括目标分支历史记录中的所有 Git 提交，而“压缩”将它们扁平化为一个提交。

令人困惑的是，“squash”并不是它自己的命令。相反，您可以在运行git merge或git rebase命令时分别选择“压缩和合并”或“压缩和变基”作为选项。

默认情况下，拉取请求 (PR) 将是合并提交，因此在合并 PR 后，工作分支的整个历史将被合并，加上一个额外的提交（“Merge pull request #21 from branch ...”） .

另一方面，您可以将您的存储库默认设置为“压缩和合并”，这意味着合并的 PR 将只产生一个提交，而不是从工作分支中带来所有提交。

为什么有人会使用 Squash 提交？

压缩提交的好处是您可以保留“干净”的 Git 提交历史记录。由于开发人员是出了名的……让我们说“精确”……那么整洁的提交历史听起来绝对棒极了。但它不是。

你可以看出为什么我对专业精神印象深刻——整个工程组织都非常致力于拥有干净的提交历史，以至于他们将“压缩和合并”作为默认设置！

不幸的是，拥有干净的提交历史的好处就到此为止了——历史可能是干净的，但日常工作需要的信息，压缩的提交不能够满足。

根据定义，压缩提交会丢失信息。我喜欢把它想象成一个黑洞，信息在黑洞中变成“霍金辐射”，在这种特殊情况下，它以开发人员的挫败感为单位进行衡量。

Squash Commit 的压倒性弱点

你会对 squash 提交感到失望，如果你使用Git Lens检查一条运行的生产线时[git blame](https://www.git-scm.com/docs/git-blame)，你永远不会学到所有东西。

在公司使用git blame查看历史记录，我的老板和同事看到“Merge pull request #237”，没有其他信息。如果不手动查找，我什至找不到 PR 的主题！多么令人沮丧！

我会尽职尽责地提取原始 PR 和票证，试图了解为什么这行特定的代码会发生变化，但我不知道。您知道 PR 经常如何一次更改数百行代码吗？是的…

我可以用一根手指指望我需要一次实际恢复整个压缩提交的次数，这是一次 PR 的戏剧性回滚，将我们的整个路线图推迟了整整一个月。

其余时间，我会做我的正常工作，尝试在“你能在一天结束前把它交给 QA 吗？”的截止日期前修复错误。当我检查一条线时，我不知道为什么它被改变了，因为压缩提交。

为什么我不想压缩我的合并提交

看，我也喜欢干净的提交历史记录，但缺点会削弱日常工作。虽然很高兴知道“在修复另一个错误时它坏了”，但一次 squash 提交并没有给我足够的信息。

假设我知道我的老板在 18 个月前通过检查它更改了某行代码git blame。在这一点上，他肯定不知道他为什么要改变它，即使他能抽出时间帮我调查一下。

通过压缩提交，我得到的信息更少：我只能找出导致行被更改的错误修复或功能，而不是行被更改的实际原因，这还不足以继续下去。

虽然如果每一行都有一两个代码注释会很棒，但我们都知道大多数开发人员并不是这样工作的——当我查看新的 React 代码库时，我通常会看到不到 1% 的代码实际上有任何注释。

解决方案是常规合并，而不是压缩提交

这里有一个超级简单的解决方案，它实际上是默认的——只是不要压缩。我想知道的并不多，但它让一切变得不同：

• refactor：我的老板是否“重构”了这段代码以使其更具可读性或可维护性，希望不影响实际功能？
• chore：我的老板是否在做一些不应该影响生产代码的清理“杂务”，例如添加代码注释或测试？
• fix：我的老板是否“修复”了一个确定的问题，如果是，这段代码破坏的具体问题是什么？
• feat：我的老板是否实施了一项新功能，例如创建具有面向用户功能的全新组件？

关注提交信息是一种伟大的文化，但重视 PR 的文化却很糟糕，会导致开发人员对公司很失望。

因为压缩提交是默认的，需要会花费数小时来修复错误，因为没有人记得任何给定的代码片段应该做什么。

Have a nice day, Happy coding.