我曾经尝试过修改我的Mercurial提交以创建漂亮的历史记录。我可能把两个不相关的事情放在一个提交里，或者我可能做了几次提交，它们可以更好地理解为一个单一的提交，但最终这似乎是浪费时间，我也克服了历史记录不完美的小尴尬。
你还这样做吗？这对你有什么价值，为什么你不再这样做了，你曾经这样做过吗，或者你正在考虑开始这样做?
如果我正在为Linux内核做贡献，显然这将是值得我的时间投入的，因为否则Linus会拒绝我的补丁，但是在我看来，dvcs用户的一个大错误是想象他们的项目就像Linux内核一样。我的项目通常只有几个开发人员。
这不值得花费精力。
只要“技巧”很好，你最好让历史保持丑陋，准确地反映出工作是如何完成的，而不是你希望工作如何完成。
当我深入研究历史记录时，一半的时间我在问“这以前是什么样子？”但是另一半时间我在问“为什么会变成这个样子”，我想看到开发人员的失败尝试，即使他宁愿抹去他曾经试图走过一条没有结果的路。
我努力清理我的修订历史。我的工作流程是进行一些小的但有意义的编辑，提交更改，重复此过程，直到进行了一系列较大的修改。然后我回去重新组织/分组提交，形成功能原子提交，并将这些修改后的提交推出去。这样其他开发人员就可以看到创建功能差异的提交，而不是大量琐碎的提交。这样在发生回归时更容易调试。
如果这是一个可以预期会在不同版本之间来回切换的应用程序，例如从旧版本分支出来以维护不同版本，那么我认为拥有干净和准确的提交消息对于项目来说是一种有价值的工具。
如果您只是进行增量更新，并且很少有可能在罕见情况下破坏构建，那么我不会过多地关注它们是否非常准确。
如果你只是追加历史记录并查看最新版本，那么这对你来说并不重要。
最近我在一个项目上工作，有人通过在两个分支之间应用大型补丁来进行“合并”。我通过查找引入功能的更改以查看随附的测试来发现它。浪费了很多时间。
您还将看到合并引入的新维度使二分法变得更加困难。它不再仅仅是左或右。
我试图记住提交注释将在后续的注释视图中出现。因此，我试图解释提交更改的意图和总体影响，而不是更改本身。
