我应该多久向源代码控制提交一次更改?在每个小特性之后，还是只在大特性之后?
我正在开发一个项目，有一个长期的功能要实现。目前，我在完成每一大块工作后，即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而，我对这种模式感到担忧。在一个富有成效的工作中，我可能会提交10次。鉴于我使用的是Subversion，这些提交会影响整个存储库，所以我想知道做这么多次是否真的是一个好做法?
当前回答
你现在的模式说得通。请记住如何使用这个源代码控制:如果您必须回滚，或者如果您想做一个不同的?在这些情况下，你所描述的块看起来就像是正确的差异:差异将准确地显示在实现bug #(在签入日志中指定)时发生了什么变化，或者确切地显示用于实现特性的新代码是什么。类似地，回滚一次只会触及一个东西。
其他回答
如果您正在进行重大更改，并且担心会影响其他使用代码的人，那么您可以创建一个新的分支，然后在更改完成后合并回主干。
不要提交实际上不起作用的代码。不要将存储库用作备份解决方案。
相反，以自动的方式在本地备份不完整的代码。时间机器会照顾我，还有很多其他平台的免费程序。
我仍然相信“经常承诺，早承诺”这句话。我更喜欢像Mercurial这样去中心化的风投，提交几件事情并在以后将其推向上游是没有问题的。
这确实是一个常见的问题，但真正的问题是:您能提交未完成的代码吗?
当您说您担心“提交会影响整个存储库”时，您是指整个存储库的修订号会增加吗?我不知道Subversion使用多少位来存储它，但我非常确定您不会用完修订号!多次提交不是问题。你可以承诺的次数是隔壁人的十倍，而你根本不会增加你的碳足迹。
单个函数或方法应该根据其功能命名，如果名称太长，则说明它的功能太多。我尝试将相同的规则应用于签入:签入注释应该准确地描述更改完成的内容，如果注释太长，则可能一次更改太多。
好吧，你可以有自己的分支，你可以随时提交，当你完成你的特性时，你可以将它合并到主干。
关于提交的频率，我是这样想的，如果我的硬盘崩溃了，而我没有提交一些东西，这对我来说有多痛苦-这个东西对我来说大约是2个小时的工作。
当然，我从不提交不能编译的东西。
