我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?
我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?
我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?
我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?
当前回答
如果你在一个不会被释放的分支上工作,提交总是安全的。
然而,如果您与其他开发人员共享它,提交不可工作的代码可能会有点烦人(特别是如果它在一个重要的地方)。通常情况下,我只提交那些有效“工作”的代码——并不是说它已经经过了充分的测试,而是我已经确定它确实可以编译,并且不会立即失败。
如果您正在使用集成的错误跟踪器,如果您已经修复了两个错误,那么单独提交可能会很有帮助,这样提交日志就可以针对正确的错误。但是,有时一个代码更改可以修复两个错误,所以你只需要选择针对哪个错误(除非你的系统允许一个提交与多个错误相关联)。
其他回答
好吧,你可以有自己的分支,你可以随时提交,当你完成你的特性时,你可以将它合并到主干。
关于提交的频率,我是这样想的,如果我的硬盘崩溃了,而我没有提交一些东西,这对我来说有多痛苦-这个东西对我来说大约是2个小时的工作。
当然,我从不提交不能编译的东西。
每当我对编译和运行的代码进行“全面思考”时,我都会签入。这通常会持续15到60分钟。有时它可能会更长,但我总是尝试签入如果我有很多代码更改,我不想在失败的情况下重写。我通常也会确保我的代码被编译,并且在下班回家前检查。
我不会担心提交/签入“太多”。当您不得不重写某些内容时,这真的很糟糕,并且能够以小增量回滚以防万一是很好的。
我喜欢Jeff Atwood写的这篇小文章:“早报到,常报到”
我遵循开源咒语——尽早提交,经常提交。
基本上,每当我认为我添加了有用的功能(无论多么小)而没有给其他团队成员带来问题时。
这种经常提交的策略在持续集成环境中特别有用,因为它允许针对其他开发工作进行集成测试,从而及早发现问题。
每天至少一次。