我应该多久向源代码控制提交一次更改?在每个小特性之后，还是只在大特性之后?
我正在开发一个项目，有一个长期的功能要实现。目前，我在完成每一大块工作后，即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而，我对这种模式感到担忧。在一个富有成效的工作中，我可能会提交10次。鉴于我使用的是Subversion，这些提交会影响整个存储库，所以我想知道做这么多次是否真的是一个好做法?
这取决于您的源代码系统和您所拥有的其他内容。如果您正在使用Git，那么每当完成一个步骤时就提交。我使用SVN，我喜欢在完成整个功能后提交，所以，每1到5个小时提交一次。如果我使用CVS，我也会这么做。
你现在的模式说得通。请记住如何使用这个源代码控制:如果您必须回滚，或者如果您想做一个不同的?在这些情况下，你所描述的块看起来就像是正确的差异:差异将准确地显示在实现bug #(在签入日志中指定)时发生了什么变化，或者确切地显示用于实现特性的新代码是什么。类似地，回滚一次只会触及一个东西。
每当我对编译和运行的代码进行“全面思考”时，我都会签入。这通常会持续15到60分钟。有时它可能会更长，但我总是尝试签入如果我有很多代码更改，我不想在失败的情况下重写。我通常也会确保我的代码被编译，并且在下班回家前检查。
我不会担心提交/签入“太多”。当您不得不重写某些内容时，这真的很糟糕，并且能够以小增量回滚以防万一是很好的。
好吧，你可以有自己的分支，你可以随时提交，当你完成你的特性时，你可以将它合并到主干。
关于提交的频率，我是这样想的，如果我的硬盘崩溃了，而我没有提交一些东西，这对我来说有多痛苦-这个东西对我来说大约是2个小时的工作。
当然，我从不提交不能编译的东西。
我遵循开源咒语——尽早提交，经常提交。
基本上，每当我认为我添加了有用的功能(无论多么小)而没有给其他团队成员带来问题时。
这种经常提交的策略在持续集成环境中特别有用，因为它允许针对其他开发工作进行集成测试，从而及早发现问题。
我也喜欢在完成一大块工作后做出承诺，通常一天要做好几次。我认为在小提交中比在大提交中更容易看到发生了什么。如果担心提交太多，可以考虑创建一个分支，并在整个特性完成后将其合并回主干。
这里有一篇相关的博客文章:编程的恐惧:尽早检查，经常检查
一方面，您必须平衡安全性和可恢复性之间的妥协，另一方面，整个项目的变更管理的便利性。
我用过的最好的方案对这个问题有两个答案。
我们使用了两个完全独立的存储库:一个是项目范围的存储库，另一个是我们自己的个人存储库(我们当时使用rcs)。
我们会定期检查我们的个人存储库，几乎每次你保存你打开的文件。因此，个人存储库基本上是一个大的、范围很长的撤销缓冲区。
一旦我们有了一段可以编译、测试的代码块，并被接受为可以普遍使用，它就会被检入到项目存储库中。
不幸的是，这个系统依赖于使用不同的VCS技术才能工作。在使用两个相同类型的VCS时，我还没有找到任何令人满意的方法来实现相同的结果。两个颠覆资料库)
但是，通过在subversion存储库中创建“个人”开发分支，我已经获得了可以接受的结果——定期地检入分支，然后在完成时合并到主干中。
我同意其中几个回答:不要签入无法编译的代码;如果您关心的是代码或其更改的“备份”，则使用个人分支或存储库;当逻辑单元完成时检入。
One other thing that I would add is that depending on your environment, the check-in rate may vary with time. For example, early in a project checking in after each functional piece of a component is complete makes sense for both safety and having a revision history (I am thinking of cases where earlier bits get refactored as later ones are being developed). Later in the project, on the other hand, entirely complete functionality becomes more important, especially during integration development/testing. A half-integration or half-fix does not help anyone.
至于每次bug修复后的签到:除非修复是微不足道的，否则绝对如此!没有什么比发现一个签入包含三个修复程序并且其中一个需要回滚更令人痛苦的了。在这种情况下，开发人员在一个区域修复了三个错误，而将哪个更改用于哪个错误修复是一场噩梦。
如果你在一个不会被释放的分支上工作，提交总是安全的。
然而，如果您与其他开发人员共享它，提交不可工作的代码可能会有点烦人(特别是如果它在一个重要的地方)。通常情况下，我只提交那些有效“工作”的代码——并不是说它已经经过了充分的测试，而是我已经确定它确实可以编译，并且不会立即失败。
如果您正在使用集成的错误跟踪器，如果您已经修复了两个错误，那么单独提交可能会很有帮助，这样提交日志就可以针对正确的错误。但是，有时一个代码更改可以修复两个错误，所以你只需要选择针对哪个错误(除非你的系统允许一个提交与多个错误相关联)。
我使用的经验法则是签入，当签入的文件组可以被单个签入注释覆盖时。
这通常是为了确保签入是原子的，并且注释可以很容易地被其他开发人员消化。
当您的更改影响到具有应用程序范围的配置文件(例如spring上下文文件或struts配置文件)时，情况尤其如此。如果您在签入之前做了几个“组”的更改，它们的影响在配置文件中会重叠，导致两个组彼此合并。
当您说您担心“提交会影响整个存储库”时，您是指整个存储库的修订号会增加吗?我不知道Subversion使用多少位来存储它，但我非常确定您不会用完修订号!多次提交不是问题。你可以承诺的次数是隔壁人的十倍，而你根本不会增加你的碳足迹。
单个函数或方法应该根据其功能命名，如果名称太长，则说明它的功能太多。我尝试将相同的规则应用于签入:签入注释应该准确地描述更改完成的内容，如果注释太长，则可能一次更改太多。
我仍然相信“经常承诺，早承诺”这句话。我更喜欢像Mercurial这样去中心化的风投，提交几件事情并在以后将其推向上游是没有问题的。
这确实是一个常见的问题，但真正的问题是:您能提交未完成的代码吗?
我觉得你不用太担心多久来一次。重要的是什么，什么时候，为什么。说你必须每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测试的标签……或者类似的东西。
我并不是说这是一个好的模式;我只是想指出，如何“完成”取决于你的团队/公司的政策。
