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

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

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

这通常是每隔几个小时。

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

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

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

一方面，您必须平衡安全性和可恢复性之间的妥协，另一方面，整个项目的变更管理的便利性。

我用过的最好的方案对这个问题有两个答案。

我们使用了两个完全独立的存储库:一个是项目范围的存储库，另一个是我们自己的个人存储库(我们当时使用rcs)。

我们会定期检查我们的个人存储库，几乎每次你保存你打开的文件。因此，个人存储库基本上是一个大的、范围很长的撤销缓冲区。

一旦我们有了一段可以编译、测试的代码块，并被接受为可以普遍使用，它就会被检入到项目存储库中。

不幸的是，这个系统依赖于使用不同的VCS技术才能工作。在使用两个相同类型的VCS时，我还没有找到任何令人满意的方法来实现相同的结果。两个颠覆资料库)

但是，通过在subversion存储库中创建“个人”开发分支，我已经获得了可以接受的结果——定期地检入分支，然后在完成时合并到主干中。

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

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

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

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

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