源码管理是开发者们最好的朋友。在分布式世界，分享代码、跟踪改变、出现问题后退回的能力是不可缺少的。

一个对初学者来说经常出现的问题是“我提交什么？多久提交一次？”我的回答是将改变变小并且越“原子化”越好。下面我会解释。

Atomic Commits

一个原子改变就是一个任务或者一个修复。

最近我收到一封邮件，里面有关于我正在写的的一个Web App的一个布局改变的列表和一个需要修复的bug。所有的改变都非常普通，一个方法是简单的执行所有的改变和修复，然后提交。然而，如果修复bug过程中产生了新的错误或者根本没有修复该怎么办呢？

一般的最好的做法是回滚到你的上一次提交，正确修复bug，然后再一次提交。但是，如果这么做了，你就会丢失所有的布局改变(正常运行的)并且你需要重新做同样的工作。同样，提交新的“修复bug修复产生的bug”也不是一个好方法。

作为替代，提交bug修复为一个改动，布局改变为另一个改动，这样你就可以简单地会滚到bug修复之前而不会影响到布局改动的了。我甚至要说吧每一个布局改动都分开提交，因为这样就会使改动布局或者回滚也更加简单了（而不会影响其它）。

在写新功能的时候，一个原子改动将总是由复数文件组成，因为布局文件、后端代码、新的源都可能被增加或者改变。你不想把这一切都分开提交，因为如果你想回滚到没有新功能的稳定版本时，你需要回滚复数的改动，这会使人困惑。这样的原子改动在合并功能到新的分支时也是很有用的，因为只需要简单地选择一个改动合并就可以了。我使用这种方法很多次了，也成功了很多次。

版本控制新人的常见想法是在工作日的最后提交修改，或者在任何我喜欢的时候提交，或者完成任何一项小事时提交。避开那些诱惑并且考虑什么是原子工作以及只有原子工作做完后才提交改动。这将使你的提交历史变得荣昌，但是最后会使你的整个项目在修复bug、增删功能和回滚更加灵活。

原子方法

• 分开提交每个bug修复或者任务
• 只有一块工作做完后才提交
• 分开提交每个布局改动
• 一起提交新功能

优势

• 容易不影响其他部分地回滚
• 容易做其他修改
• 容易合并功能到其他分支

扩展阅读

如果你想要更深入了解Atomic Commit，或者想看一些例子，看一下这篇文章，如果你SVN阵营的，看这个和这个

---

翻译自这里