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

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

我遵循开源咒语——尽早提交，经常提交。

基本上，每当我认为我添加了有用的功能(无论多么小)而没有给其他团队成员带来问题时。

这种经常提交的策略在持续集成环境中特别有用，因为它允许针对其他开发工作进行集成测试，从而及早发现问题。

想想看。

(只要你登记的东西是安全的)

我也喜欢在完成一大块工作后做出承诺，通常一天要做好几次。我认为在小提交中比在大提交中更容易看到发生了什么。如果担心提交太多，可以考虑创建一个分支，并在整个特性完成后将其合并回主干。

这里有一篇相关的博客文章:编程的恐惧:尽早检查，经常检查

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

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

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