我应该多久向源代码控制提交一次更改?在每个小特性之后，还是只在大特性之后?
我正在开发一个项目，有一个长期的功能要实现。目前，我在完成每一大块工作后，即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而，我对这种模式感到担忧。在一个富有成效的工作中，我可能会提交10次。鉴于我使用的是Subversion，这些提交会影响整个存储库，所以我想知道做这么多次是否真的是一个好做法?
当前回答
当你完成了一些代码，并且不会把别人搞砸，如果他们在更新中得到它。
请确保你的评论是正确的。
其他回答
我也喜欢在完成一大块工作后做出承诺，通常一天要做好几次。我认为在小提交中比在大提交中更容易看到发生了什么。如果担心提交太多，可以考虑创建一个分支，并在整个特性完成后将其合并回主干。
这里有一篇相关的博客文章:编程的恐惧:尽早检查，经常检查
每天至少一次。
这取决于您的源代码系统和您所拥有的其他内容。如果您正在使用Git，那么每当完成一个步骤时就提交。我使用SVN，我喜欢在完成整个功能后提交，所以，每1到5个小时提交一次。如果我使用CVS，我也会这么做。
当您说您担心“提交会影响整个存储库”时，您是指整个存储库的修订号会增加吗?我不知道Subversion使用多少位来存储它，但我非常确定您不会用完修订号!多次提交不是问题。你可以承诺的次数是隔壁人的十倍，而你根本不会增加你的碳足迹。
单个函数或方法应该根据其功能命名，如果名称太长，则说明它的功能太多。我尝试将相同的规则应用于签入:签入注释应该准确地描述更改完成的内容，如果注释太长，则可能一次更改太多。
如果您正在进行重大更改，并且担心会影响其他使用代码的人，那么您可以创建一个新的分支，然后在更改完成后合并回主干。
