我喜欢Jeff Atwood写的这篇小文章:“早报到，常报到”

不要提交实际上不起作用的代码。不要将存储库用作备份解决方案。

相反，以自动的方式在本地备份不完整的代码。时间机器会照顾我，还有很多其他平台的免费程序。

正如其他人所说的，尝试提交一个足够“完整”的逻辑块，它不会妨碍其他开发人员(例如，它构建并通过自动化测试)。

每个开发团队/公司必须为每个分支定义什么是“足够完整”的。例如，你可能有只需要代码来构建的功能分支，也需要代码来通过自动化测试的Trunk，以及表明某些东西已经通过QA测试的标签……或者类似的东西。

我并不是说这是一个好的模式;我只是想指出，如何“完成”取决于你的团队/公司的政策。

一方面，您必须平衡安全性和可恢复性之间的妥协，另一方面，整个项目的变更管理的便利性。

我用过的最好的方案对这个问题有两个答案。

我们使用了两个完全独立的存储库:一个是项目范围的存储库，另一个是我们自己的个人存储库(我们当时使用rcs)。

我们会定期检查我们的个人存储库，几乎每次你保存你打开的文件。因此，个人存储库基本上是一个大的、范围很长的撤销缓冲区。

一旦我们有了一段可以编译、测试的代码块，并被接受为可以普遍使用，它就会被检入到项目存储库中。

不幸的是，这个系统依赖于使用不同的VCS技术才能工作。在使用两个相同类型的VCS时，我还没有找到任何令人满意的方法来实现相同的结果。两个颠覆资料库)

但是，通过在subversion存储库中创建“个人”开发分支，我已经获得了可以接受的结果——定期地检入分支，然后在完成时合并到主干中。

我同意其中几个回答:不要签入无法编译的代码;如果您关心的是代码或其更改的“备份”，则使用个人分支或存储库;当逻辑单元完成时检入。

One other thing that I would add is that depending on your environment, the check-in rate may vary with time. For example, early in a project checking in after each functional piece of a component is complete makes sense for both safety and having a revision history (I am thinking of cases where earlier bits get refactored as later ones are being developed). Later in the project, on the other hand, entirely complete functionality becomes more important, especially during integration development/testing. A half-integration or half-fix does not help anyone.

至于每次bug修复后的签到:除非修复是微不足道的，否则绝对如此!没有什么比发现一个签入包含三个修复程序并且其中一个需要回滚更令人痛苦的了。在这种情况下，开发人员在一个区域修复了三个错误，而将哪个更改用于哪个错误修复是一场噩梦。

我喜欢每30-60分钟提交一次更改，只要它编译干净，并且在单元测试中没有回归。