我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?
我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?
我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?
我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?
当前回答
当你完成了一些代码,并且不会把别人搞砸,如果他们在更新中得到它。
请确保你的评论是正确的。
其他回答
如果您正在进行重大更改,并且担心会影响其他使用代码的人,那么您可以创建一个新的分支,然后在更改完成后合并回主干。
想想看。
(只要你登记的东西是安全的)
每次我完成一项任务时,我都会做出承诺。这通常需要30分钟到1小时。
如果你的版本控制注释超过了一两句话,你可能没有经常提交。
我仍然相信“经常承诺,早承诺”这句话。我更喜欢像Mercurial这样去中心化的风投,提交几件事情并在以后将其推向上游是没有问题的。
这确实是一个常见的问题,但真正的问题是:您能提交未完成的代码吗?