多久将更改提交给源代码管理？[关闭]

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

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

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

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

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

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

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

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

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

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

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

如果您的版本控制注释长于一两个句子，那么您提交的次数可能不够。

我遵循开源的口头禅（释义）-尽早提交，经常提交。

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

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

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

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

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

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

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

我认为您不必为多久担心一次。这里重要的是什么，何时何地。说必须每3个小时或每24个小时提交一次，这确实没有任何意义。在有东西要提交的时候提交，如果没有，就不要提交。

这是我推荐的版本控制最佳实践的摘录：

[...]如果您要同时对一个项目进行许多更改，请将它们分成逻辑部分，并在多个会话中进行提交。这使跟踪单个更改的历史记录变得更加容易，这将在以后尝试查找和修复错误时为您节省大量时间。例如，如果要实现功能A，B和C并修复错误1、2和3，则总共应至少进行六次提交，每个功能一次，每个错误一次。如果您正在开发大型功能部件或进行大量的重构，请考虑将工作分解为更小的部分，并在完成每个部分后进行提交。同样，在对多个逻辑模块实施独立更改时，即使更改是较大更改的一部分，也要分别将更改提交给每个模块。

理想情况下，永远不要离开办公室，不要在硬盘驱动器上进行任何未提交的更改。如果您正在从事变更会影响其他人的项目，请考虑使用分支来实施您的变更，并在完成后将其合并回主干。在提交对其他项目（也就是其他人）所依赖的库或项目的更改时，请确保不要通过提交不会编译的代码来破坏其构建。但是，拥有无法编译的代码并不是避免提交的借口。请改用分支。[...]

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

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

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

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

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

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

当您考虑一下。

（只要您检查的是安全的）

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

我同意以下几种回应：不要检入无法编译的代码；如果您关注的是代码或其更改的“备份”，请使用个人分支或存储库；检查逻辑单元何时完成。

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

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

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

这通常是每两个小时。

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

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

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

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

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

在提交的频率上，我是这样想的，如果我的硬盘崩溃并且我没有做任何事情，那对我来说将有多大痛苦-这对我来说大概是两个小时的工作时间。

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

每天至少一次。

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

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

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

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

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

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

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

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

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

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

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

我仍然相信“经常提交，尽早提交”这一短语。我更喜欢像Mercurial这样的分散式VCS，并且可以提交一些东西并将其稍后推向上游没有问题。

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

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

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