我同意其中几个回答:不要签入无法编译的代码;如果您关心的是代码或其更改的“备份”，则使用个人分支或存储库;当逻辑单元完成时检入。

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修复后的签到:除非修复是微不足道的，否则绝对如此!没有什么比发现一个签入包含三个修复程序并且其中一个需要回滚更令人痛苦的了。在这种情况下，开发人员在一个区域修复了三个错误，而将哪个更改用于哪个错误修复是一场噩梦。

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

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

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

每个开发团队/公司必须为每个分支定义什么是“足够完整”的。例如，你可能有只需要代码来构建的功能分支，也需要代码来通过自动化测试的Trunk，以及表明某些东西已经通过QA测试的标签……或者类似的东西。

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

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

我遵循开源咒语——尽早提交，经常提交。

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

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

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

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

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