我应该多久向源代码控制提交一次更改?在每个小特性之后，还是只在大特性之后?
我正在开发一个项目，有一个长期的功能要实现。目前，我在完成每一大块工作后，即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而，我对这种模式感到担忧。在一个富有成效的工作中，我可能会提交10次。鉴于我使用的是Subversion，这些提交会影响整个存储库，所以我想知道做这么多次是否真的是一个好做法?
当前回答
正如其他人所说的，尝试提交一个足够“完整”的逻辑块，它不会妨碍其他开发人员(例如，它构建并通过自动化测试)。
每个开发团队/公司必须为每个分支定义什么是“足够完整”的。例如，你可能有只需要代码来构建的功能分支，也需要代码来通过自动化测试的Trunk，以及表明某些东西已经通过QA测试的标签……或者类似的东西。
我并不是说这是一个好的模式;我只是想指出，如何“完成”取决于你的团队/公司的政策。
其他回答
想想看。
(只要你登记的东西是安全的)
好吧，你可以有自己的分支，你可以随时提交，当你完成你的特性时，你可以将它合并到主干。
关于提交的频率，我是这样想的，如果我的硬盘崩溃了，而我没有提交一些东西，这对我来说有多痛苦-这个东西对我来说大约是2个小时的工作。
当然，我从不提交不能编译的东西。
每次我完成一项任务时，我都会做出承诺。这通常需要30分钟到1小时。
如果你的版本控制注释超过了一两句话，你可能没有经常提交。
我个人会提交每一组已完成/稳定/编译的逻辑代码，并尽量在没有提交我当天所做的事情的情况下下班。
