我喜欢每30-60分钟提交一次更改，只要它编译干净，并且在单元测试中没有回归。

正如其他人所说的，尝试提交一个足够“完整”的逻辑块，它不会妨碍其他开发人员(例如，它构建并通过自动化测试)。

每个开发团队/公司必须为每个分支定义什么是“足够完整”的。例如，你可能有只需要代码来构建的功能分支，也需要代码来通过自动化测试的Trunk，以及表明某些东西已经通过QA测试的标签……或者类似的东西。

我并不是说这是一个好的模式;我只是想指出，如何“完成”取决于你的团队/公司的政策。

这取决于您的源代码系统和您所拥有的其他内容。如果您正在使用Git，那么每当完成一个步骤时就提交。我使用SVN，我喜欢在完成整个功能后提交，所以，每1到5个小时提交一次。如果我使用CVS，我也会这么做。

如果您正在进行重大更改，并且担心会影响其他使用代码的人，那么您可以创建一个新的分支，然后在更改完成后合并回主干。

我觉得你不用太担心多久来一次。重要的是什么，什么时候，为什么。说你必须每3小时或每24小时完成一次任务是毫无意义的。有事情要承诺时就承诺，没有事情就不要承诺。

以下是我推荐的版本控制最佳实践的摘录:

[...] If you are doing many changes to a project at the same time, split them up into logical parts and commit them in multiple sessions. This makes it much easier to track the history of individual changes, which will save you a lot of time when trying to find and fix bugs later on. For example, if you are implementing feature A, B and C and fixing bug 1, 2 and 3, that should result in a total of at least six commits, one for each feature and one for each bug. If you are working on a big feature or doing extensive refactoring, consider splitting your work up into even smaller parts, and make a commit after each part is completed. Also, when implementing independent changes to multiple logical modules, commit changes to each module separately, even if they are part of a bigger change. Ideally, you should never leave your office with uncommitted changes on your hard drive. If you are working on projects where changes will affect other people, consider using a branch to implement your changes and merge them back into the trunk when you are done. When committing changes to libraries or projects that other projects—and thus, other people—depend on, make sure you don’t break their builds by committing code that won’t compile. However, having code that doesn’t compile is not an excuse to avoid committing. Use branches instead. [...]

我仍然相信“经常承诺，早承诺”这句话。我更喜欢像Mercurial这样去中心化的风投，提交几件事情并在以后将其推向上游是没有问题的。

这确实是一个常见的问题，但真正的问题是:您能提交未完成的代码吗?