我应该多久向源代码控制提交一次更改?在每个小特性之后,还是只在大特性之后?

我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。

然而,我对这种模式感到担忧。在一个富有成效的工作中,我可能会提交10次。鉴于我使用的是Subversion,这些提交会影响整个存储库,所以我想知道做这么多次是否真的是一个好做法?


当前回答

我也喜欢在完成一大块工作后做出承诺,通常一天要做好几次。我认为在小提交中比在大提交中更容易看到发生了什么。如果担心提交太多,可以考虑创建一个分支,并在整个特性完成后将其合并回主干。

这里有一篇相关的博客文章:编程的恐惧:尽早检查,经常检查

其他回答

我没有每次提交的具体时间限制,我倾向于在测试通过并且我对代码满意的情况下提交。我不会提交无法编译的代码,或者在失败的情况下我不愿意返回的状态

我觉得你不用太担心多久来一次。重要的是什么,什么时候,为什么。说你必须每3小时或每24小时完成一次任务是毫无意义的。有事情要承诺时就承诺,没有事情就不要承诺。

以下是我推荐的版本控制最佳实践的摘录:

[...] If you are doing many changes to a project at the same time, split them up into logical parts and commit them in multiple sessions. This makes it much easier to track the history of individual changes, which will save you a lot of time when trying to find and fix bugs later on. For example, if you are implementing feature A, B and C and fixing bug 1, 2 and 3, that should result in a total of at least six commits, one for each feature and one for each bug. If you are working on a big feature or doing extensive refactoring, consider splitting your work up into even smaller parts, and make a commit after each part is completed. Also, when implementing independent changes to multiple logical modules, commit changes to each module separately, even if they are part of a bigger change. Ideally, you should never leave your office with uncommitted changes on your hard drive. If you are working on projects where changes will affect other people, consider using a branch to implement your changes and merge them back into the trunk when you are done. When committing changes to libraries or projects that other projects—and thus, other people—depend on, make sure you don’t break their builds by committing code that won’t compile. However, having code that doesn’t compile is not an excuse to avoid committing. Use branches instead. [...]

每当我对编译和运行的代码进行“全面思考”时,我都会签入。这通常会持续15到60分钟。有时它可能会更长,但我总是尝试签入如果我有很多代码更改,我不想在失败的情况下重写。我通常也会确保我的代码被编译,并且在下班回家前检查。

我不会担心提交/签入“太多”。当您不得不重写某些内容时,这真的很糟糕,并且能够以小增量回滚以防万一是很好的。

我仍然相信“经常承诺,早承诺”这句话。我更喜欢像Mercurial这样去中心化的风投,提交几件事情并在以后将其推向上游是没有问题的。

这确实是一个常见的问题,但真正的问题是:您能提交未完成的代码吗?

如果你在一个不会被释放的分支上工作,提交总是安全的。

然而,如果您与其他开发人员共享它,提交不可工作的代码可能会有点烦人(特别是如果它在一个重要的地方)。通常情况下,我只提交那些有效“工作”的代码——并不是说它已经经过了充分的测试,而是我已经确定它确实可以编译,并且不会立即失败。

如果您正在使用集成的错误跟踪器,如果您已经修复了两个错误,那么单独提交可能会很有帮助,这样提交日志就可以针对正确的错误。但是,有时一个代码更改可以修复两个错误,所以你只需要选择针对哪个错误(除非你的系统允许一个提交与多个错误相关联)。