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

我正在开发一个项目,有一个长期的功能要实现。目前,我在完成每一大块工作后,即每一个子特性实现和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. [...]

其他回答

我个人会提交每一组已完成/稳定/编译的逻辑代码,并尽量在没有提交我当天所做的事情的情况下下班。

不要提交实际上不起作用的代码。不要将存储库用作备份解决方案。

相反,以自动的方式在本地备份不完整的代码。时间机器会照顾我,还有很多其他平台的免费程序。

我使用的经验法则是签入,当签入的文件组可以被单个签入注释覆盖时。

这通常是为了确保签入是原子的,并且注释可以很容易地被其他开发人员消化。

当您的更改影响到具有应用程序范围的配置文件(例如spring上下文文件或struts配置文件)时,情况尤其如此。如果您在签入之前做了几个“组”的更改,它们的影响在配置文件中会重叠,导致两个组彼此合并。

我喜欢Jeff Atwood写的这篇小文章:“早报到,常报到”

我遵循开源咒语——尽早提交,经常提交。

基本上,每当我认为我添加了有用的功能(无论多么小)而没有给其他团队成员带来问题时。

这种经常提交的策略在持续集成环境中特别有用,因为它允许针对其他开发工作进行集成测试,从而及早发现问题。