多久提交一次源代码pipe理更改？
我应该多久更改一次源代码pipe理？ 每个小function之后，还是仅适用于大型function？
我正在做一个项目，并有一个长期的function来实现。 目前，我正在承诺每一个工作，即每个子function实施和错误修复。 我甚至在发现一个bug之后为某个特性添加了一个新的testing块之后就提交了。
不过，我很担心这种模式。 在一个富有成效的工作日，我可能会做10次提交。 考虑到我使用的是Subversion，这些提交会影响整个存储库，所以我想知道这样做是否是一个很好的做法？
任何时候，我完成编译和运行的代码的“全面思考”，我签入。 这通常在15-60分钟之间结束。 有时可能会更长，但我总是试着检查是否有很多代码更改，如果发生故障，我不想重写。 我也通常确保我的代码编译，并在我回家前一天的工作结束时登记。
我不会担心做太多的提交/签入。 当你必须重写某些东西的时候真的很糟糕，为了以防万一，能够以小的增量回滚。
当你说你担心你的“提交会影响整个仓库”时 – 你是指整个仓库修订号增加的事实吗？ 我不知道有多less位Subversion用来存储它，但我敢肯定，你不会用完版本号！ 许多提交都不是问题。 你可以像隔壁的家伙一样频繁地犯十次，你根本不会增加你的碳足迹。
一个单一的函数或方法应该被命名为它的名字，如果这个名字太长，那么这个名字太多了。 我尝试将相同的规则应用到签入： 签入评论应该准确地描述更改所完成的内容，如果评论太长，我可能会立即更改太多。
我喜欢杰夫·阿特伍德（Jeff Atwood）的这篇小文章： 提早入住，经常入住
我个人承诺完成/稳定/编译的每一个逻辑代码组，尽量不离开那天做的那一天。
如果您正在进行重大更改并担心影响其他人员处理代码，则可以创build一个新分支，然后在更改完成后合并回主干。
每次我完成一项任务，我都会犯下。 通常需要30分钟到1小时。
不要提交实际上不工作的代码。 不要将您的存储库用作备份解决scheme。
而应以自动方式在本地备份不完整的代码。 Time Machine照顾我，其他平台上有很多免费程序。
如果您的版本控制评论比一个或两个句子长，您可能不够经常。
我遵循开源的口头禅（释义） – 提前承诺，经常承诺。
基本上每当我想我已经添加了有用的function（无论小），而不会为其他团队成员带来问题。
这种提交 – 经常策略在持续集成环境中特别有用，因为它允许对其他开发工作进行集成testing，从而及早发现问题。
我使用的经验法则是当一组签入的文件可以由一个签入注释覆盖时签入。
这通常是为了确保签入是primefaces性的，并且评论可以容易地被其他开发者消化。
当更改影响到应用程序范围很宽的configuration文件（例如spring上下文文件或strutsconfiguration文件）时尤其如此。 如果您在签入之前进行了多个“组”更改，则其影响会重叠在configuration文件中，从而导致两个组合并彼此。
我不认为你应该多less时间担心。 这里重要的是什么，什么时候和为什么。 说你必须每3小时或每24小时承诺才没有意义。 当你有事情承诺，不，如果你没有。
以下是我推荐的版本控制最佳实践摘录：
[…]如果您同时对项目进行了许多更改，则将它们分成逻辑部分，并在多个会话中提交。 这使得跟踪单个更改的历史变得更加容易，这将在以后尝试查找和修复错误时为您节省大量时间。 例如，如果您正在实现functionA，B和C，并修复了错误1，错误2和错误3，这将导致总共至less6次提交，每个function一个，每个错误一个。 如果您正在开发一个大function或进行大量重构，请考虑将工作分成更小的部分，并在每部分完成后进行提交。 另外，在对多个逻辑模块进行独立更改时，即使它们是更大更改的一部分，也要分别向每个模块提交更改。
理想情况下，你不应该离开你的办公室在硬盘驱动器上的未经改变的变化。 如果您正在处理变更会影响其他人的项目，请考虑使用分支来实施更改，并在完成后将其合并回主干。 当提交对其他项目（也就是其他人）所依赖的库或项目的更改时，请确保不要通过提交不会编译的代码来破坏构build。 但是，不编译代码不是避免提交的借口。 改用分支。 […]
你目前的模式是有道理的。 记住你如何使用这个源代码控制：如果你必须回滚，或者如果你想做一个差异呢？ 在这些情况下，您所描述的块看起来确实是正确的差异：差异会显示在实现bug＃（在checkin log中指定）时确切地发生了什么变化，或者确切地说是新代码实现function的原因。 类似的，回滚一次只能触及一件事情。
在完成大量的工作之后，我也很愿意承诺，这通常是每天几次。 我认为看到小提交中发生的事情比大事更容易。 如果您担心提交次数过多，则可以考虑在完成整个function时创build分支并将其合并回主干。
这里有一个相关的博客文章： 编码恐怖：提前入住，经常入住
正如其他人所说，尝试提交一个足够完整的逻辑块，以至于不会以其他开发者的方式（例如，构build并通过自动化testing）。
每个开发团队/公司必须为每个分支定义什么是“完整的”。 例如，您可能拥有需要代码构build的function分支，还需要代码才能通过自动化testing的Trunk，以及指示某些内容已通过QAtesting的标签等等。
我并不是说这是一个很好的模式， 我只是指出如何完成取决于你的团队/公司的政策。
你考虑的那一刻。
（只要你检查是安全的）
取决于你的源代码系统，你有什么地方。 如果你使用的是Git，那么只要你完成一个步骤就提交。 我使用SVN，我喜欢在完成整个function时提交，因此，每隔一到五个小时。 如果我使用CVS，我也会这样做。
我同意几个答复：不检查不会编译的代码; 如果您的担心是对代码或其更改进行“备份”，则使用个人分支或存储库; 检查逻辑单元何时完成。
我还要补充的另外一点是，根据您的环境，入住率可能会随着时间而变化。 例如，在组件的每个function部件完成之后检查项目的早期对于安全性和修订历史都是有意义的（我正在考虑在后面的部分被开发的时候，前面的部分被重构的情况）。 另一方面，在项目的后期，完整的function变得更加重要，特别是在集成开发/testing期间。 半集成或半固定不能帮助任何人。
至于在每个错误修复后检查：除非修复是微不足道的，绝对！ 没有什么比发现一个检查包含三个修复并且其中一个修复需要被回滚更痛苦的了。 通常情况下，开发人员似乎在这种情况下修复了一个区域中的三个错误，然后解开哪个修改就是一个噩梦。
我喜欢每30-60分钟进行一次修改，只要它编译干净，unit testing没有回退。
那么，你可以有你自己的分支，你可以随时进行任何你喜欢的，当你完成你的function，你可以将它合并到主干。
就Commits的频率来说，我这样想，如果我的硬盘坏掉了，而且我没有做出什么事情，那对我来说会有多大的痛苦 – 这个东西对我来说大概需要2个小时的工作。
当然，我从来没有提交过不能编译的东西。
每天至less一次。
我没有提交每个提交的具体时间限制，我倾向于一旦testing通过，我对代码感到满意。 我不会提交那些不能编译的代码，或者是在这种状态下我不会觉得恢复到出现故障
你必须平衡安全性和可恢复性之间的妥协，同时也要平衡整个项目的变更pipe理。
我用过的最好的scheme有两个答案。
我们使用了2个完全独立的存储库：一个是项目范围的存储库，另一个是我们自己的个人存储库（我们当时使用的是rcs）。
我们会定期检查我们的个人存储库，几乎每次保存打开的文件。 因此，个人存储库基本上是一个大的，长期的撤销缓冲区。
一旦我们有了一段可编译的代码，testing好了，被接受为可以用于一般用途，它被检入到项目库中。
不幸的是，这个系统依赖于使用不同的VCS技术是可行的。 在使用两个相同types的VCS（例如两个Subversion版本库）时，我还没有find任何令人满意的方法来达到相同的结果。
但是，通过在Subversion版本库中创build“个人”开发分支，我有了可以接受的结果 – 定期检查分支，并在完成后合并到主干中。
如果你在一个不会被释放的分支上工作，一个提交总是安全的。
但是，如果您与其他开发人员共享，则提交非工作代码可能会有点烦人（尤其是在重要的地方）。 通常我只提交有效的“代码” – 不是经过了充分的testing，而是确定它确实是编译的，而不是立即失败。
如果您正在使用集成的错误跟踪器，那么如果您修复了两个错误，则可以进行单独的提交，这样提交日志可以对付错误。 但是，有时一次代码更改会修复两个错误，所以您只需select一个代码（除非您的系统允许一个提交与多个错误关联）
我仍然相信“经常犯下，早早犯下”的说法。 我更喜欢像Mercurial这样的分散式VCS，并且承诺几件事情并在稍后将其推上去是没有问题的。
这确实是一个常见的问题，但真正的问题是：你能否提交未完成的代码？
每当你完成了一些可行的代码，如果他们得到更新，就不会把别人搞砸了。
并请确保您正确评论。
我也喜欢定期检查。 每次我朝着自己的目标迈出了一步，
这通常是每隔几个小时 。
我的困难是find愿意并能够执行如此多的代码评论的人 。
我们的公司政策是，我们需要先进行代码审查，然后才能检查任何内容，这是有道理的，但部门中并不总是有人有时间立即执行代码审查。 可能的解决scheme：
- 每次入住更多的工作; less检查==less评语。
- 更改公司签入政策。 如果我刚刚做了一些重构，unit testing都是绿色的，也许我可以放松规则？
- 搁置变更，直到有人可以执行审查并继续工作。 如果评论者不喜欢你的代码，你必须重新devise，这可能会有问题。 通过“搁置”更改来杂耍任务的不同阶段可能变得杂乱无章。
