我应该多久向源代码控制提交一次更改?在每个小特性之后，还是只在大特性之后?
我正在开发一个项目，有一个长期的功能要实现。目前，我在完成每一大块工作后，即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而，我对这种模式感到担忧。在一个富有成效的工作中，我可能会提交10次。鉴于我使用的是Subversion，这些提交会影响整个存储库，所以我想知道做这么多次是否真的是一个好做法?
当前回答
想想看。
(只要你登记的东西是安全的)
其他回答
每次我完成一项任务时，我都会做出承诺。这通常需要30分钟到1小时。
我个人会提交每一组已完成/稳定/编译的逻辑代码，并尽量在没有提交我当天所做的事情的情况下下班。
当您说您担心“提交会影响整个存储库”时，您是指整个存储库的修订号会增加吗?我不知道Subversion使用多少位来存储它，但我非常确定您不会用完修订号!多次提交不是问题。你可以承诺的次数是隔壁人的十倍，而你根本不会增加你的碳足迹。
单个函数或方法应该根据其功能命名，如果名称太长，则说明它的功能太多。我尝试将相同的规则应用于签入:签入注释应该准确地描述更改完成的内容，如果注释太长，则可能一次更改太多。
我使用的经验法则是签入，当签入的文件组可以被单个签入注释覆盖时。
这通常是为了确保签入是原子的，并且注释可以很容易地被其他开发人员消化。
当您的更改影响到具有应用程序范围的配置文件(例如spring上下文文件或struts配置文件)时，情况尤其如此。如果您在签入之前做了几个“组”的更改，它们的影响在配置文件中会重叠，导致两个组彼此合并。
我喜欢Jeff Atwood写的这篇小文章:“早报到，常报到”
