我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?

我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。

然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?


当前回答

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

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

其他回答

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

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

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

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

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

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

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

我没有每次提交的具体时间限制,我倾向于在测试通过并且我对代码满意的情况下提交。我不会提交无法编译的代码,或者在失败的情况下我不愿意返回的状态

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

这通常是每隔几个小时。

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

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

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

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

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

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

如果您正在进行重大更改,并且担心会影响其他使用代码的人,那么您可以创建一个新的分支,然后在更改完成后合并回主干。