在DVCS中创建漂亮的修订历史是否值得？ [英] Is it worth the effort to create pretty revision history in a DVCS?

问题描述

我曾经回去编辑我的Mercurial承诺，试图创造一个美丽的历史。我可能会把两个不相关的东西放到一个提交中，或者我可能提交了几个更好理解为单个提交的提交，但最终看起来像是浪费时间，而且我忽略了不完美历史的小小尴尬。

你仍然这样做吗？为什么这对你是值得的，为什么你不再这样做，你是否曾经这样做，或者你是否想要开始？

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

解决方案

我努力清理修订历史记录。我的工作流程遵循一个小而有意义的编辑，提交，重复，直到做出一系列更大的修改。然后我回去重新排列/组织提交到功能上的原子提交，并推出那些修改后的提交。这允许其他开发人员看到创建功能差异的提交，而不是大规模的提交。让它更容易在发生问题时调试回归。

I used to go back and edit my Mercurial commits to try to create a pretty history. I might have put two unrelated things into one commit, or I might have made several commits that were better understood as a single commit, but eventually it seemed like a waste of time and I got over the minor embarrassment of having less than perfect history.

Do you still do this? Why is it worthwhile to you, why don't you do it anymore, did you ever do this, or are you thinking of starting?

If I was contributing to the Linux kernel this would obviously be worth my time because Linus would reject my patch otherwise, but IMO one of the big mistakes of dvcs users is to imagine their project is like the Linux kernel. My projects usually only have a few developers.

解决方案

I make an effort to clean up my revision history. My workflow goes along the lines of make a small but meaningful edit, commit, repeat until some series of larger modifications are made. Then I go back and re-order/group commits together into functionally atomic commits, and push those revised commits out. This allows other developers to see commits which create functional differences, as opposed to massive walls of trivial commits. Makes it easier to debug regressions when they occur.

这篇关于在DVCS中创建漂亮的修订历史是否值得？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！