我应该多久提交一次对源代码管理的更改？在每个小功能之后，还是仅对于大功能？

我正在做一个项目，并且有一个长期功能要实施。目前，我要在每一项工作之后投入工作，即，实现每个子功能并修复错误。发现错误后，甚至为某些功能添加了新的测试块后，我什至提交。

但是，我担心这种模式。在富有成效的工作中，我可能会提交10次提交。鉴于我正在使用Subversion，所以这些提交会影响整个存储库，所以我想知道这样做是否真的是一个好习惯吗？

解决方案

我喜欢每30-60分钟提交一次更改，只要它可以干净地编译并且在单元测试中没有任何退步即可。

我亲自提交每个逻辑组的已完成/稳定/编译的代码，并尽量不遗漏当天所做的事情。

我们考虑一下的那一刻。

(只要我们检查的是安全的)

如果我们要进行重大更改，并且担心影响其他使用该代码的人，则可以创建一个新分支，然后在更改完成后合并回主干。

取决于源代码系统以及我们所拥有的其他内容。如果我们使用的是Git，则在完成任何步骤后都进行提交。我使用SVN，并且喜欢在完成整个功能时提交，因此，每1至5个小时一次。如果我使用的是CVS，我会做同样的事情。

我们当前的模式是有道理的。请记住如何使用此源代码管理：如果必须回滚，或者想要进行比较，该怎么办？在这种情况下，我们描述的块看上去恰好是正确的区别：差异将向我们显示在实施Bug＃(在签入日志中指定)中发生的变化，或者确切地说明实现功能的新代码。同样，回滚一次只会涉及一件事。

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

而是以自动方式在本地备份我们不完整的代码。 Time Machine照顾我，还有许多其他平台的免费程序。

每当我完成编译和运行的代码的"完整思考"时，我都会签入。通常情况下，结束时间为15-60分钟。有时可能会更长，但是我总是尝试签入是否有很多代码更改，如果发生故障我不想重写。我通常还确保我的代码可以编译，并在工作回家后的一天结束之前检入。

我不会担心进行"过多"的提交/签入。当我们必须重写某些内容时，它确实很烂，并且能够以较小的增量进行回滚以防万一，这是很好的。

好吧，我们可以拥有自己的分支，可以随时向其提交，完成功能后，可以将其合并到主干中。

在提交的频率上，我是这样想的，如果我的硬盘崩溃了，而我没有做任何事情，那对我来说将是多么痛苦。大约2个小时的工作时间对我来说是一件痛苦的事情。

当然，我从不提交无法编译的内容。

每天至少一次。

每当我完成一项任务时，我都会承诺。通常需要30分钟到1小时。

我喜欢Jeff Atwood撰写的这篇小文章：提早入住，经常入住

我遵循开源的口头禅(释义)尽早提交，经常提交。

基本上，每当我认为我添加了有用的功能(但是很小)时，都不会给其他团队成员带来麻烦。

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

我还喜欢在完成每天通常几次的工作后再提交。我认为，看到小提交比大提交更容易。如果我们担心提交过多，可以考虑在整个功能完成后创建分支并将其合并回主干。

这是相关的博客文章：编码恐怖：提早入住，经常入住

我没有每次提交的具体时限，我倾向于在测试通过后提交，并且对代码感到满意。我不会提交无法编译的代码，否则将处于无法恢复的状态

我们一方面必须权衡安全性和可恢复性，另一方面要为整个项目简化变更管理之间的折衷。

我使用的最佳方案对此问题有两个答案。

我们使用了2个完全独立的存储库：一个是项目范围的存储库，另一个是我们自己的个人存储库(当时我们使用rcs)。

每当我们保存打开的文件时，我们都会非常有规律地检查我们的个人存储库。因此，个人存储库基本上是一个很大的，长距离的撤消缓冲区。

一旦我们有一大堆可以编译，可以正常测试的代码，并被接受为可以普遍使用，就将其检入到项目存储库中。

不幸的是，该系统只能使用不同的VCS技术。使用两个相同类型的VCS(例如，两个Subversion存储库)时，我还没有找到令人满意的方法来获得相同的结果

但是，通过在Subversion存储库中创建"个人"开发分支，并定期检查该分支，然后在完成后合并到主干中，我获得了可接受的结果。

我同意以下几种回答：不要检入无法编译的代码；如果我们担心要对代码或者其更改进行"备份"，请使用个人分支或者存储库；检查逻辑单元何时完成。

我要补充的另一件事是，根据环境，入住率可能会随时间而变化。例如，在组件的每个功能部件完成之后的项目检入中，从安全性和具有修订历史的角度来说都是有意义的(我考虑的是在开发较早的位时重构较早的位的情况)。另一方面，在项目的后期，尤其是在集成开发/测试过程中，完全完整的功能变得尤为重要。半集成或者半修复对任何人都没有帮助。

至于在每个错误修复之后进行检查：除非该修复是无关紧要的，否则绝对可以！没有比发现一个检查包含三个修复程序且其中一个需要回滚的修复程序更痛苦的了。在这种情况下，开发人员似乎经常会在一个区域内修复三个错误，并消除将哪个更改归结为哪个错误修复是一场噩梦。

如果我们正在不被释放的分支上工作，那么提交始终是安全的。

但是，如果我们要与其他开发人员共享它，则提交不起作用的代码可能会有些烦人(尤其是在重要的地方)。通常，我只提交有效"起作用"的代码，不是经过充分测试的代码，而是我确定它确实可以编译并且不会立即失败。

如果我们使用的是集成的错误跟踪器，则在修复了两个错误之后进行单独的提交可能会有所帮助，以便使提交日志可以与正确的错误相对应。但是话又说回来，有时一个代码更改可以修复两个错误，因此我们只需要选择针对哪个错误即可(除非系统允许一次提交与多个错误相关联)

我的经验法则是，当要检入的文件组可以由一个检入注释覆盖时，就是检入。

通常，这是为了确保签入是原子性的，并且其他开发人员可以轻松地提取注释。

当更改影响到具有应用程序范围的配置文件(例如spring上下文文件或者struts配置文件)时，尤其如此。如果在签入之前进行几个"组"更改，则它们的影响会在配置文件中重叠，从而导致两个组彼此合并。

当我们说我们担心"提交会影响整个存储库"时，我们是在指整个存储库的修订版号增加的事实吗？我不知道Subversion用来存储多少位，但是我很确定我们不会用完修订号！许多提交都不是问题。我们可以像隔壁的那个家伙一样承诺十次，而我们根本不会增加碳足迹。

应该为单个函数或者方法的功能命名，如果名称太长，则说明函数执行过多。我尝试对签入应用相同的规则：签到注释应准确描述更改完成的内容，如果注释太长，则可能一次更改太多。

我仍然相信"经常提交，尽早提交"这一短语。我更喜欢像Mercurial这样的分散式VCS，毫无疑问，我们可以提交几件事并将其稍后推向上游。

这确实是一个常见问题，但真正的问题是：我们可以提交未完成的代码吗？

我认为我们不必为多久担心一次。这里重要的是什么，何时何地。说必须每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. [...]

每当我们完成一些有效的代码时，如果其他人在更新中得到了帮助，就不会搞砸其他人。

并且请确保我们发表正确的评论。

我也喜欢定期检查。那就是我每次都朝着目标迈出了完整的一步。

通常每隔几个小时。

我的困难是找到一个愿意并且能够执行这么多代码审查的人。

我们的公司政策是，在签入任何内容之前，我们需要进行代码审查，这是有道理的，但是部门中并不总是有人有时间立即执行代码审查。可能的解决方案：

• 每次入住需要更多工作；较少签到==较少评论。
• 更改公司签到政策。如果我刚刚进行了一些重构，并且单元测试全部运行为绿色，也许我可以放宽规则了？
• 搁置更改，直到有人可以执行审阅并继续工作为止。如果审阅者不喜欢代码，而我们必须重新设计，则可能会出现问题。通过"搁置"更改来处理任务的不同阶段可能会变得混乱。

正如其他人所说，尝试提交一个足够"完整"的逻辑块，以至于它不会妨碍其他开发人员的方式(例如，它构建并通过了自动化测试)。

每个开发团队/公司都必须为每个分支机构定义"足够完整"的内容。例如，我们可能具有仅需要构建代码的功能分支，也需要通过自动测试的代码的Trunk，以及表明某些内容已通过QA测试...等的标签。

我并不是说这是一个很好的模式。我只是指出，"完成"的方式取决于我们团队/公司的政策。