我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?
我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?
我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?
我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?
当前回答
每次我完成一项任务时,我都会做出承诺。这通常需要30分钟到1小时。
其他回答
如果您正在进行重大更改,并且担心会影响其他使用代码的人,那么您可以创建一个新的分支,然后在更改完成后合并回主干。
当您说您担心“提交会影响整个存储库”时,您是指整个存储库的修订号会增加吗?我不知道Subversion使用多少位来存储它,但我非常确定您不会用完修订号!多次提交不是问题。你可以承诺的次数是隔壁人的十倍,而你根本不会增加你的碳足迹。
单个函数或方法应该根据其功能命名,如果名称太长,则说明它的功能太多。我尝试将相同的规则应用于签入:签入注释应该准确地描述更改完成的内容,如果注释太长,则可能一次更改太多。
每当我对编译和运行的代码进行“全面思考”时,我都会签入。这通常会持续15到60分钟。有时它可能会更长,但我总是尝试签入如果我有很多代码更改,我不想在失败的情况下重写。我通常也会确保我的代码被编译,并且在下班回家前检查。
我不会担心提交/签入“太多”。当您不得不重写某些内容时,这真的很糟糕,并且能够以小增量回滚以防万一是很好的。
当你完成了一些代码,并且不会把别人搞砸,如果他们在更新中得到它。
请确保你的评论是正确的。
我喜欢Jeff Atwood写的这篇小文章:“早报到,常报到”