我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?
我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?
我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?
我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?
当前回答
这取决于您的源代码系统和您所拥有的其他内容。如果您正在使用Git,那么每当完成一个步骤时就提交。我使用SVN,我喜欢在完成整个功能后提交,所以,每1到5个小时提交一次。如果我使用CVS,我也会这么做。
其他回答
当您说您担心“提交会影响整个存储库”时,您是指整个存储库的修订号会增加吗?我不知道Subversion使用多少位来存储它,但我非常确定您不会用完修订号!多次提交不是问题。你可以承诺的次数是隔壁人的十倍,而你根本不会增加你的碳足迹。
单个函数或方法应该根据其功能命名,如果名称太长,则说明它的功能太多。我尝试将相同的规则应用于签入:签入注释应该准确地描述更改完成的内容,如果注释太长,则可能一次更改太多。
好吧,你可以有自己的分支,你可以随时提交,当你完成你的特性时,你可以将它合并到主干。
关于提交的频率,我是这样想的,如果我的硬盘崩溃了,而我没有提交一些东西,这对我来说有多痛苦-这个东西对我来说大约是2个小时的工作。
当然,我从不提交不能编译的东西。
我遵循开源咒语——尽早提交,经常提交。
基本上,每当我认为我添加了有用的功能(无论多么小)而没有给其他团队成员带来问题时。
这种经常提交的策略在持续集成环境中特别有用,因为它允许针对其他开发工作进行集成测试,从而及早发现问题。
如果您正在进行重大更改,并且担心会影响其他使用代码的人,那么您可以创建一个新的分支,然后在更改完成后合并回主干。
正如其他人所说的,尝试提交一个足够“完整”的逻辑块,它不会妨碍其他开发人员(例如,它构建并通过自动化测试)。
每个开发团队/公司必须为每个分支定义什么是“足够完整”的。例如,你可能有只需要代码来构建的功能分支,也需要代码来通过自动化测试的Trunk,以及表明某些东西已经通过QA测试的标签……或者类似的东西。
我并不是说这是一个好的模式;我只是想指出,如何“完成”取决于你的团队/公司的政策。