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

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

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

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

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

如果你在一个不会被释放的分支上工作，提交总是安全的。

然而，如果您与其他开发人员共享它，提交不可工作的代码可能会有点烦人(特别是如果它在一个重要的地方)。通常情况下，我只提交那些有效“工作”的代码——并不是说它已经经过了充分的测试，而是我已经确定它确实可以编译，并且不会立即失败。

如果您正在使用集成的错误跟踪器，如果您已经修复了两个错误，那么单独提交可能会很有帮助，这样提交日志就可以针对正确的错误。但是，有时一个代码更改可以修复两个错误，所以你只需要选择针对哪个错误(除非你的系统允许一个提交与多个错误相关联)。

如果你的版本控制注释超过了一两句话，你可能没有经常提交。