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

然而，如果您与其他开发人员共享它，提交不可工作的代码可能会有点烦人(特别是如果它在一个重要的地方)。通常情况下，我只提交那些有效“工作”的代码——并不是说它已经经过了充分的测试，而是我已经确定它确实可以编译，并且不会立即失败。

如果您正在使用集成的错误跟踪器，如果您已经修复了两个错误，那么单独提交可能会很有帮助，这样提交日志就可以针对正确的错误。但是，有时一个代码更改可以修复两个错误，所以你只需要选择针对哪个错误(除非你的系统允许一个提交与多个错误相关联)。

每当我对编译和运行的代码进行“全面思考”时，我都会签入。这通常会持续15到60分钟。有时它可能会更长，但我总是尝试签入如果我有很多代码更改，我不想在失败的情况下重写。我通常也会确保我的代码被编译，并且在下班回家前检查。

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

一方面，您必须平衡安全性和可恢复性之间的妥协，另一方面，整个项目的变更管理的便利性。

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

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

我们会定期检查我们的个人存储库，几乎每次你保存你打开的文件。因此，个人存储库基本上是一个大的、范围很长的撤销缓冲区。

一旦我们有了一段可以编译、测试的代码块，并被接受为可以普遍使用，它就会被检入到项目存储库中。

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

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

我觉得你不用太担心多久来一次。重要的是什么，什么时候，为什么。说你必须每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测试的标签……或者类似的东西。

我并不是说这是一个好的模式;我只是想指出，如何“完成”取决于你的团队/公司的政策。