先听个恶心的例子。您会看到问题F00-123已解决。这是您熟悉的子系统中的错误，因此您的直觉会告诉您最有可能导致该错误的原因。为了证实您的怀疑，您决定查看错误是如何修复的。你花了很长时间搜索整个版本历史，直到你将这个bugfix的范围缩小到连续4个提交，它们各自的提交信息是：daotweaks（daotweaks）、moar、Fixes，并删除了一些调试信息（removedebugstuff).每个提交的变更集似乎很大，在十几个文件中有数百个更改。“我他妈的@#$%%^&”，你刚想骂你妈又停了下来，心里最难听的脏话也没有说出来。“此错误修复不应超过三行代码！”。上面的例子听起来是不是很熟悉？许多开发人员只是将版本控制系统视为一堆文件的备份。这些历史备份除了允许您在某个时间点检索文件内容外没有任何用处。以下建议可以帮助您将版本控制系统从备份系统转变为用于通信和文档编制的宝贵工具。1.每次提交只做一次修改如果修复F00-123和F00-233，重构一个类，在界面上加一两个按钮，一次提交把整个工程文件中的tab改成空白如果是空白，那么基本上没有人可以查看F00-123的错误修复。只有您知道哪些修改是该错误修复的一部分，但您可能会在一周后忘记它。如果一周后你发现原来的bugfix导致了另一个更严重的问题，那么你就完蛋了，你不能使用hgbackout或gitrevert来撤消你的更改，因为那会删除除bugfix之外的所有更改撤消它也意味着你一周的努力都白费了。上面问题的解决方案是“onechangepercommit”，对于什么算作“onechange”并没有硬性规定，但是如果你能用一句话，不要用“and”，如果不能的话用语言描述你所做的一切，然后你就完成了。分布式版本控制系统的一个很好的特性是，如果你的工作目录中有很多不相关的更改，你可以用它来帮助你清理你造成的混乱），但是***不要首先弄得一团糟。在你开始修改代码之前，先确定你要做什么，你要怎么做，然后认真地关注你要修改的点。似乎不太可能在不弄清楚如何改进它的情况下修改一段代码。你发现了错误，看到了一些蹩脚的代码，以及一些你好奇想了解更多的东西。无论你多么想做，都不要分心。这些发现很有价值，用笔记本或TODO文件把它们记下来（jotthemdown），在完成当前任务之前不要试图解决那些问题。这不仅仅是提交更好。当你沉浸在解决某个编程问题的时候，脑子里满是关于这个问题的一堆细节。如果这时候你跳到想一些其他的问题，那么你就会忘记原来问题的细节，回到原来的问题上去。花了一些时间才回到最初的问题。你需要减少任务切换（minimizetaskswitches）来提高你的工作效率。当然，有时你会发现不解决一些其他问题就很难完成当前的任务。这个时候最简单的方法就是用hgshelve或者gitstash暂时存放你未完成的改动，把两个有问题的改动分开，提交依赖的改动，然后回到你原来的任务。2.每次提交必须包含完整的修改。如果修改分布在多个提交中，则很难审查修改。通常这是由于同时解决了太多问题造成的。如果你不能吃那么多，而是吃那么多，那么当你想存一些的时候，你会发现大部分都没有吃完。完全的。同时关注太多问题会导致***需要很长时间才能提交完整的更改。（原文是：Focusingononetaskatthetimetakesyoulongwaytocommitcompletechanges。但我觉得作者的本意应该是：Focusingontoomuchtaskstakesyoulongwaytocommitcompletechanges.)有些Editing需要很长时间，所以如果你在中间的某个时候弄错了，你无法从头开始，所以你需要在这个过程中保存一些中间版本。幸运的是，分布式版本控制系统允许你保存很多中间版本，但是***只提交一个修改到中央仓库（centralrepository），你可以提交任意数量的中间版本，在***使用hghistedit或者gitrebase将多个中间版本合并到一个修订集中。另一种方法也是我最喜欢的方法，因为它将中间版本与最终修改版本分开。此方法使用Git的索引，或MercurialQueues中的补丁来保存最新的正确（Bug-free）中间版本，每次您进行新更改时更新此索引/补丁，如果您出错，可以使用它们来恢复你的工作目录。我喜欢将其视为用于版本控制的单槽快速保存。像“修复”、“提交”这样的提交消息不包含任何有用的信息。如果别人想看版本历史，像这样的commit信息只会迫使他们去阅读所有的代码变更，费时费力。编写如此简短且不清楚的提交消息可能会为您节省一分钟，但会浪费其他人的时间。一个好的提交消息可以让查看者知道代码的哪一部分被修改了，修改的方式如何，他们不需要看你的代码：SomeClass:useblehinsteadofxyzzyinsomeMethod(fixesFOO-123)4.评论解释为什么会这样done修改假设每个代码更改都有一个很好的理由/原因，但如果没有记录这个原因/原因，整个代码库将面临以下风险：其他开发人员不理解为什么原始代码是这样写的。当他们修改代码时，可能会引入一些原作者已经发现或避免的问题。其他开发人员认为原始代码以这种方式编写一定有（充分的）理由，所以不要碰它。他们将这些代码视为一个黑盒，然后添加各种复杂的变通方法来避免修改原始代码。***导致这个代码库变得臃肿，代码变得难以理解。如果你有足够的理由破坏项目的规范或协议，你必须在你的代码中写下这个理由作为注释：-xyzzy(bars);+//Ourbarsarealreadysorted,soblehismuchfasterthanxyzzy+bleh(bars); 如果你代码符合规范，并且你的代码中没有需要注意的细微之处，那么就没有必要在代码中写你的文档注释。但是还是有必要让人知道为什么新代码比旧代码好（特别是当新代码引入新问题的时候），所以还是有必要在commitmessage中写明原因：SomeClass:Don'tflushcachesinsomeMethodThecachesareflushedautomaticallyattheendofeachrequest.如果修改解决了已知问题，请确保在提交信息中包含票号（错误跟踪系统中的票），以便其他开发人员在查看版本历史时可以清楚地知道修改是在什么情况下进行的。5.不要提交被注释掉的代码我们使用版本控制系统只是为了保留旧版本？！为什么要注释掉这些代码？代码会起作用吗？它会工作吗？它曾经奏效过吗？注释代码是我们应该支持还是应该放弃的东西？注释掉的代码是没有用的，因为每当开发人员阅读注释代码时，总会有一些未回答的问题，这只会让开发人员感到困惑，并分散开发人员更好地关注有用代码的注意力。提交注释掉的代码只有一个原则，那就是：原文链接：http://dev.solita.fi/2013/07/04/whats-in-a-good-commit.html翻译链接：http://kb.cnblogs.com/page/181762/http://kb.cnblogs.com/page/181762/
