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

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-60分钟提交一次更改，只要它编译干净，并且在单元测试中没有回归。

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

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

我个人会提交每一组已完成/稳定/编译的逻辑代码，并尽量在没有提交我当天所做的事情的情况下下班。

我也喜欢定期检查。那就是每次我都朝着我的目标迈进了一步。

这通常是每隔几个小时。

我的困难是找到一个愿意并且能够执行这么多代码审查的人。

我们公司的政策是，在签入任何东西之前，我们需要进行代码审查，这是有道理的，但在部门中并不总是有人有时间立即执行代码审查。可能的解决方式:

每次签入需要更多的工作;更少的签到=更少的评论。 改变公司签到政策。如果我刚刚做了一些重构，单元测试全部运行绿色，也许我可以放松规则? 搁置变更，直到有人能够执行评审并继续工作。如果审阅者不喜欢你的代码，你就必须重新设计，这就会产生问题。通过“搁置”更改来处理任务的不同阶段可能会变得混乱。