是否值得努力在DVCS中创建漂亮的修订历史记录?

时间:2009-02-02 18:54:16

标签: git mercurial dvcs bazaar

我曾经回去编辑我的Mercurial提交,试图创建一个漂亮的历史。我可能已经将两个不相关的东西放入一个提交中,或者我可能已经做了几个提交,这些提交被更好地理解为单个提交,但最终它似乎浪费时间并且我克服了不完美历史的轻微尴尬。

你仍然这样做吗?为什么对你有价值,你为什么不再这样做,你有没有这样做,或者你想要开始?

如果我为Linux内核做贡献,这显然值得我花时间,因为Linus会拒绝我的补丁,但IMO dvcs用户的一个重大错误就是想象他们的项目就像Linux内核。我的项目通常只有少数开发人员。

5 个答案:

答案 0 :(得分:10)

这不值得努力。

只要'小费'很漂亮,你最好让历史变得丑陋并准确地反映出工作的结果,而不是你希望工作的结果。

当我正在挖掘历史时,有一半时间我会问“这曾经是什么样的?”但另一半时间我问“为什么这最终看起来像这样”我希望看到开发人员的失败尝试,即使他宁愿抹去这样一个事实,即他曾试图沿着一条没路的路走下去好吧。

答案 1 :(得分:5)

我努力清理修订历史记录。我的工作流程沿着做一个小但有意义的编辑,提交,重复的行,直到做出一系列更大的修改。然后我返回并重新命令/将提交组合成功能原子提交,并推送那些修改后的提交。这允许其他开发人员查看创建功能差异的提交,而不是大量提交的大量墙。当回归发生时,可以更容易地调试回归。

答案 2 :(得分:1)

如果它是一个可以预期在修订版之间来回转换的应用程序,例如从较旧的转换分支以维护不同的版本,我会考虑使用干净且准确的提交消息作为项目的一个有价值的工具。 / p>

如果你只是在进行增量更新而几乎没有可能在罕见的条件下打破构建,我就不会太费心了,因为它们非常准确。

答案 3 :(得分:0)

如果您只附加历史记录并查看最新版本,则无关紧要。

我最近正在开展一个项目,通过在两个分支上应用大型补丁,有人进行了“合并”。我发现它是通过寻找一个引入功能的变化来看看它带来了哪些测试。浪费了很多时间。

你还会看到合并引入的新维度使得二分法变得更加困难。它不再只是左或右。

答案 4 :(得分:0)

我正在努力记住提交注释稍后会出现在注释视图中。因此,我试图解释承诺变更的意图和整体效果,而不是变化本身。