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

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

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


当前回答

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

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

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

其他回答

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

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

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

你现在的模式说得通。请记住如何使用这个源代码控制:如果您必须回滚,或者如果您想做一个不同的?在这些情况下,你所描述的块看起来就像是正确的差异:差异将准确地显示在实现bug #(在签入日志中指定)时发生了什么变化,或者确切地显示用于实现特性的新代码是什么。类似地,回滚一次只会触及一个东西。

我喜欢每30-60分钟提交一次更改,只要它编译干净,并且在单元测试中没有回归。

我使用的经验法则是签入,当签入的文件组可以被单个签入注释覆盖时。

这通常是为了确保签入是原子的,并且注释可以很容易地被其他开发人员消化。

当您的更改影响到具有应用程序范围的配置文件(例如spring上下文文件或struts配置文件)时,情况尤其如此。如果您在签入之前做了几个“组”的更改,它们的影响在配置文件中会重叠,导致两个组彼此合并。