我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?
我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?
我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?
我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?
当前回答
我也喜欢在完成一大块工作后做出承诺,通常一天要做好几次。我认为在小提交中比在大提交中更容易看到发生了什么。如果担心提交太多,可以考虑创建一个分支,并在整个特性完成后将其合并回主干。
这里有一篇相关的博客文章:编程的恐惧:尽早检查,经常检查
其他回答
想想看。
(只要你登记的东西是安全的)
我喜欢Jeff Atwood写的这篇小文章:“早报到,常报到”
我喜欢每30-60分钟提交一次更改,只要它编译干净,并且在单元测试中没有回归。
好吧,你可以有自己的分支,你可以随时提交,当你完成你的特性时,你可以将它合并到主干。
关于提交的频率,我是这样想的,如果我的硬盘崩溃了,而我没有提交一些东西,这对我来说有多痛苦-这个东西对我来说大约是2个小时的工作。
当然,我从不提交不能编译的东西。
我个人会提交每一组已完成/稳定/编译的逻辑代码,并尽量在没有提交我当天所做的事情的情况下下班。