多久提交一次对源代码控制的更改？ [关闭]答案

【问题标题】：How often to commit changes to source control? [closed]多久提交一次对源代码控制的更改？ [关闭]
【发布时间】：2008-09-20 05:37:10
【问题描述】：

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

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

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

【问题讨论】：

伙计，这个问题不是基于意见的，而是一个完全有效且答案正确的问题。提交是一种重要的技能，其想法是您必须提交您在代码库中添加的有效且稳定的增强/功能/hotFix，包括描述性提交消息。如果一天结束并且你想离开，你不能只是提交一个损坏的代码并说你明天会修复它，因为最好使用 rebase 和 merge 来保留重要的提交和消息并压缩不必要的，如果你只想保持一个临时状态，你必须使用 git stash
为了避免歧义，如果在某些特定情况下您需要提交并推送未完成的代码，在您回来并想再次继续该分支后，当您完成该事情时，您必须修改之前不完整的提交，然后推送它。如何保持工作树的清洁和对回顾有用完全取决于您，但在查找和解决非常隐藏或微妙的错误或功能不佳时相信与否，如果您拥有干净和专业的工作树，这将是一个巨大的帮助想使用 git 调试工具，例如 - git blame 或 git bisect

标签： version-control

【解决方案1】：

只要我完成了对可编译和运行的代码的“完整思考”，我就会签到。这通常最终在 15-60 分钟之间。有时它可能会更长，但我总是尝试检查是否有很多我不想在失败的情况下重写的代码更改。我通常还会确保我的代码能够编译，并在我下班回家前签到。

我不会担心做出“太多”的提交/签入。当您必须重写某些内容时，它真的很糟糕，并且能够以小增量回滚以防万一。

【讨论】：

用这种方法破坏构建的可能性急剧增加。请注意，如果您没有验证签入的自动化测试 - 人们会因为您阻止他们而敲门。
如果您使用分布式版本控制系统，使用这种方法破坏构建的可能性不会增加。
虽然构建中断的数量会随着更频繁的提交而增加，但修复中断的时间会减少，撤消提交所损失的时间也会减少。频繁的提交也会带来许多其他好处。如果我破坏了构建，我希望尽快破坏它，并提交一个小提交，以便我可以快速修复它。
如果你投入了 2 周的工作量，你肯定不想去挖掘一个巨大的提交来查看哪一点代码破坏了构建。频繁提交允许您将问题隔离到更小的代码库，因为您知道只有一小部分代码发生了变化。
@MikeJ 这一切都取决于您如何使用源代码控制。此外，如果您使用的是 Git 之类的东西，并且在自己的分支中工作，那么您不会影响其他团队成员的构建，甚至不会影响 CI/CD 管道。

【解决方案2】：

当您说您担心“提交会影响整个存储库”时——您是指整个存储库的修订号增加的事实吗？我不知道 Subversion 使用多少位来存储它，但我很确定你不会用完修订号！ 多次提交都不是问题。你可以提交十倍于隔壁的人，而且你根本不会增加你的碳足迹。

单个函数或方法应该以它的作用命名，如果名称太长，它就做得太多了。我尝试对签入应用相同的规则：签入注释应准确描述更改完成的内容，如果注释太长，我可能一次更改太多。

【讨论】：

我喜欢你的说法。如果你提交的频率是十次，那根本不会有问题（但如果你提交的次数是你提交次数的 1/10，那很可能会出现问题）。

【解决方案3】：

我喜欢 Jeff Atwood 的这篇小文章：Check In Early, Check In Often

【讨论】：

【解决方案4】：

我亲自提交所有已完成/稳定/编译的逻辑代码组，并尽量不要在没有提交我那天所做的事情的情况下离开这一天。

【讨论】：

【解决方案5】：

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

【讨论】：

【解决方案6】：

如果你的版本控制评论超过一两句话，你可能提交的频率不够。

【讨论】：

如果它较少，你可能没有正确评论。

【解决方案7】：

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

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

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

【讨论】：

【解决方案8】：

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

【讨论】：

【解决方案9】：

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

相反，以自动方式在本地备份您的不完整代码。 Time Machine 照顾我，还有很多适用于其他平台的免费程序。

【讨论】：

或者创建一个分支。这就是他们的目的。
版本控制旨在防止数据丢失或备份。但它也不打算成为回收站。仅应提交编译的代码，但该功能不一定要完整才能进行提交。

【解决方案10】：

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

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

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

【讨论】：

【解决方案11】：

我认为您不必担心多久。这里重要的是什么，何时以及为什么。说你必须每 3 小时或每 24 小时提交一次确实没有意义。当你有事情要提交的时候就提交，如果你没有就不要提交。

这是我recommended best practices for version control的摘录：

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

理想情况下，您永远不应该带着未提交的硬盘更改离开办公室。如果您正在处理更改会影响其他人的项目，请考虑使用分支来实现您的更改，并在完成后将它们合并回主干。在提交对其他项目（以及其他人）所依赖的库或项目的更改时，请确保您不会通过提交无法编译的代码来破坏他们的构建。但是，拥有无法编译的代码并不是避免提交的借口。改用分支。 [...]

【讨论】：

【解决方案12】：

您当前的模式是有道理的。记住你是如何使用这个源代码控制的：如果你必须回滚，或者如果你想做一个差异呢？在这些情况下，您描述的块似乎完全是正确的差异：差异将准确地向您展示实现错误＃（在签入日志中指定）时发生的变化，或者准确地显示用于实现功能的新代码。同样，回滚一次只会触及一件事。

【讨论】：

【解决方案13】：

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

这是一篇相关的博文：Coding Horror: Check In Early, Check In Often

【讨论】：

+1 关于较小的提交，使其更容易跟进。没有什么比 CVS 提交中的长段落更糟糕的了。它会伤害你的眼睛和头部。

【解决方案14】：

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

每个开发团队/公司都必须为每个分支定义什么是“足够完整”。例如，您可能有只需要代码才能构建的功能分支、还需要代码才能通过自动化测试的主干，以及指示某些内容已通过 QA 测试的标签……或类似的东西。

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

【讨论】：

【解决方案15】：

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

这是通常每隔几个小时。

我的困难是找到愿意并且能够执行如此多的代码审查的人。

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

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

【讨论】：

公司的检查签入政策是明智的，但与快速备份签入不兼容。为此，我认为在分支中工作并在那里签入而不需要审查是有意义的，并且只通过合并到主干进行正式签入，并进行代码审查
@Eli- 我同意，使用分支似乎是最好的主意。我们曾经在我们的公司这样做，但后来我们停止了。我不记得确切的问题是什么 - 但我认为它变得太复杂了，对于处理发布和部署过程的人来说太复杂了。
同上以利。另一种选择是在发布之前或其他里程碑之前进行审查。审查每个签入/提交到版本控制是可怕的。太糟糕了，我会建立一个本地存储库，只是为了同时提交某个地方，直到我可以提交到“主”存储库。（我以前在 CVCS 服务器不可用时这样做过。）

【解决方案16】：

你想到它的那一刻。

（只要你签到的东西是安全的）

【讨论】：

【解决方案17】：

取决于您的源代码系统以及您拥有的其他内容。如果您使用的是 Git，请在完成一个步骤时提交。我使用 SVN，我喜欢在完成一个完整的功能时提交，所以，每隔一到五个小时。如果我使用 CVS，我也会这样做。

【讨论】：

【解决方案18】：

我同意以下几个回答：不要签入无法编译的代码；如果您担心对代码或其更改进行“备份”，请使用个人分支或存储库；逻辑单元完成后签入。

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

至于每次错误修复后的检查：除非修复是微不足道的，绝对！没有什么比发现一个签入包含三个修复程序并且其中一个需要回滚更痛苦的了。通常情况下，在这种情况下，开发人员似乎在一个区域修复了三个错误，并且展开哪个更改去哪个错误修复是一场噩梦。

【讨论】：

【解决方案19】：

我喜欢每 30-60 分钟提交一次更改，只要它编译干净并且在单元测试中没有回归。

【讨论】：

【解决方案20】：

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

关于 Commits 的频率，我是这样想的，如果我的硬盘崩溃而我没有提交某事，对我来说会有多痛苦——这件事对我来说大约是 2 小时的工作.

当然，我从不提交不能编译的东西。

【讨论】：

那么，只有 2 小时的痛苦.. 对吗？为什么这么糟糕？

【解决方案21】：

每天至少一次。

【讨论】：

【解决方案22】：

我没有每次提交的具体时间限制，我倾向于在测试通过并且对代码感到满意后提交。我不会；不会提交无法编译的代码，或者在失败的情况下我不会感觉恢复到的状态

【讨论】：

【解决方案23】：

您必须一方面在安全性和可恢复性之间取得平衡，另一方面又要在整个项目的变更管理容易度之间取得平衡。

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

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

我们会定期检查我们的个人存储库，几乎每次您保存打开的文件时。因此，个人存储库基本上是一个大而长的撤消缓冲区。

一旦我们有一段代码可以编译、测试正常并被接受为准备好进行一般使用，它就会被签入项目存储库。

不幸的是，这个系统依赖于使用不同的 VCS 技术才能工作。在使用两个相同类型的 VCS（例如两个颠覆存储库）时，我没有找到任何令人满意的方法来实现相同的结果

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

【讨论】：

【解决方案24】：

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

但是，如果您与其他开发人员共享它，那么提交非工作代码可能会有点烦人（尤其是在它位于重要位置时）。通常我只提交有效“工作”的代码——不是说它已经过全面测试，而是我已经确定它确实可以编译并且不会立即失败。

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

【讨论】：

【解决方案25】：

我仍然相信“经常提交，尽早提交”这句话。我更喜欢像Mercurial 这样的去中心化VCS，提交几件事并稍后将其推送到上游是没有问题的。

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

【讨论】：

我相信未完成的代码可以提交，只要它的架构正确，这样它就可以与系统的其余部分隔离。例如，如果你在 Stack Overflow 中实现投票功能，如果 UI 尚未构建，那么没人会知道它的存在。

【解决方案26】：

每当您完成一些有效的代码并且如果他们在更新中获得它不会搞砸其他任何人。

请确保您正确评论。

【讨论】：