我应该多久向源代码控制提交一次更改?在每个小特性之后，还是只在大特性之后?
我正在开发一个项目，有一个长期的功能要实现。目前，我在完成每一大块工作后，即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而，我对这种模式感到担忧。在一个富有成效的工作中，我可能会提交10次。鉴于我使用的是Subversion，这些提交会影响整个存储库，所以我想知道做这么多次是否真的是一个好做法?
当前回答
一方面，您必须平衡安全性和可恢复性之间的妥协，另一方面，整个项目的变更管理的便利性。
我用过的最好的方案对这个问题有两个答案。
我们使用了两个完全独立的存储库:一个是项目范围的存储库，另一个是我们自己的个人存储库(我们当时使用rcs)。
我们会定期检查我们的个人存储库，几乎每次你保存你打开的文件。因此，个人存储库基本上是一个大的、范围很长的撤销缓冲区。
一旦我们有了一段可以编译、测试的代码块，并被接受为可以普遍使用，它就会被检入到项目存储库中。
不幸的是，这个系统依赖于使用不同的VCS技术才能工作。在使用两个相同类型的VCS时，我还没有找到任何令人满意的方法来实现相同的结果。两个颠覆资料库)
但是，通过在subversion存储库中创建“个人”开发分支，我已经获得了可以接受的结果——定期地检入分支，然后在完成时合并到主干中。
其他回答
我也喜欢在完成一大块工作后做出承诺，通常一天要做好几次。我认为在小提交中比在大提交中更容易看到发生了什么。如果担心提交太多，可以考虑创建一个分支，并在整个特性完成后将其合并回主干。
这里有一篇相关的博客文章:编程的恐惧:尽早检查，经常检查
你现在的模式说得通。请记住如何使用这个源代码控制:如果您必须回滚，或者如果您想做一个不同的?在这些情况下，你所描述的块看起来就像是正确的差异:差异将准确地显示在实现bug #(在签入日志中指定)时发生了什么变化，或者确切地显示用于实现特性的新代码是什么。类似地，回滚一次只会触及一个东西。
我喜欢每30-60分钟提交一次更改，只要它编译干净，并且在单元测试中没有回归。
每当我对编译和运行的代码进行“全面思考”时，我都会签入。这通常会持续15到60分钟。有时它可能会更长，但我总是尝试签入如果我有很多代码更改，我不想在失败的情况下重写。我通常也会确保我的代码被编译，并且在下班回家前检查。
我不会担心提交/签入“太多”。当您不得不重写某些内容时，这真的很糟糕，并且能够以小增量回滚以防万一是很好的。
我没有每次提交的具体时间限制，我倾向于在测试通过并且我对代码满意的情况下提交。我不会提交无法编译的代码，或者在失败的情况下我不愿意返回的状态
