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

每当我对编译和运行的代码进行“全面思考”时，我都会签入。这通常会持续15到60分钟。有时它可能会更长，但我总是尝试签入如果我有很多代码更改，我不想在失败的情况下重写。我通常也会确保我的代码被编译，并且在下班回家前检查。

我不会担心提交/签入“太多”。当您不得不重写某些内容时，这真的很糟糕，并且能够以小增量回滚以防万一是很好的。

我喜欢每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. [...]

当你完成了一些代码，并且不会把别人搞砸，如果他们在更新中得到它。

请确保你的评论是正确的。