我觉得你不用太担心多久来一次。重要的是什么，什么时候，为什么。说你必须每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. [...]

当您说您担心“提交会影响整个存储库”时，您是指整个存储库的修订号会增加吗?我不知道Subversion使用多少位来存储它，但我非常确定您不会用完修订号!多次提交不是问题。你可以承诺的次数是隔壁人的十倍，而你根本不会增加你的碳足迹。

单个函数或方法应该根据其功能命名，如果名称太长，则说明它的功能太多。我尝试将相同的规则应用于签入:签入注释应该准确地描述更改完成的内容，如果注释太长，则可能一次更改太多。

不要提交实际上不起作用的代码。不要将存储库用作备份解决方案。

相反，以自动的方式在本地备份不完整的代码。时间机器会照顾我，还有很多其他平台的免费程序。

每次我完成一项任务时，我都会做出承诺。这通常需要30分钟到1小时。

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

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

我同意其中几个回答:不要签入无法编译的代码;如果您关心的是代码或其更改的“备份”，则使用个人分支或存储库;当逻辑单元完成时检入。

One other thing that I would add is that depending on your environment, the check-in rate may vary with time. For example, early in a project checking in after each functional piece of a component is complete makes sense for both safety and having a revision history (I am thinking of cases where earlier bits get refactored as later ones are being developed). Later in the project, on the other hand, entirely complete functionality becomes more important, especially during integration development/testing. A half-integration or half-fix does not help anyone.

至于每次bug修复后的签到:除非修复是微不足道的，否则绝对如此!没有什么比发现一个签入包含三个修复程序并且其中一个需要回滚更令人痛苦的了。在这种情况下，开发人员在一个区域修复了三个错误，而将哪个更改用于哪个错误修复是一场噩梦。