这不值得努力。
只要“小费”是漂亮的，你最好让历史变得丑陋并准确地反映工作是如何产生的，而不是你希望工作是如何产生的。
当我有一半时间在挖掘历史时，我会问“这过去是什么样子的？” 但另一半时间我在问“为什么这最终看起来像这样”，我想看看开发人员的失败尝试，即使他宁愿抹去他曾经尝试过的道路不成功。
我努力清理我的修订历史。我的工作流程是进行小而有意义的编辑、提交、重复，直到进行一些较大的修改。然后我返回并将提交重新排序/组合成功能原子提交，并将那些修改后的提交推出。这允许其他开发人员看到产生功能差异的提交，而不是大量的琐碎提交。使发生回归时更容易调试回归。
如果它是一个可以预期在修订之间来回切换的应用程序，例如从旧版本分支以维护不同的版本，我会考虑拥有干净准确的提交消息作为项目的宝贵工具。
如果您只是在进行增量更新，而在极少数情况下破坏构建的可能性很小，那么我不会太在意它们是否非常准确。
如果您只附加到历史记录并查看最新版本，那对您来说并不重要。
我最近在做一个项目，有人通过在两个分支上应用一个大补丁来“合并”。我通过寻找引入了一项功能的更改来发现它，以查看随之而来的测试。浪费了很多时间。
您还将看到合并引入的新维度使二分变得更加困难。它不再只是左或右。
我试图记住提交评论稍后会出现在注释视图中。因此，我试图解释已提交更改的意图和整体效果，而不是更改本身。