在 StackOverflow 上还有另一个 thread，处理提交更改到源代码控制的频率。我想把它放在使用像 git 或 mercurial 这样的 DVCS 的上下文中。
您提交的频率和时间是多少？
您是否仅在更改时才提交更改？ 构建正确吗？
您多久和何时推送更改（或提交拉取请求或类似内容）？
您如何开发复杂的功能/进行需要涉及许多地方的复杂重构？无法构建的“私人提交”是否可以？完成后，您是将它们也推送到主存储库，还是在推送之前将所有更改捆绑到单个变更集中？
【问题讨论】：
这取决于您正在处理的分支（“开发线”）的性质。
这些 DVCS（git 或 mercurial）的主要优点是您可以轻松：
所以：
1/ 您提交的频率和时间是多少？
2/ 你是否只在正确构建时提交更改？
在私有分支上根据需要尽可能多的时间（例如，如果它编译）。
仅在单元测试通过时才提交的做法是一个很好的做法，但应仅适用于“官方”（如“可以发布或“推送””）分支：在您的私人分支中，如果您合并了一个 gazillon 时间需要。
唯一的事情是：在你的主开发分支上重放它们之前，做一些合并 --interactive 来重新组织你在私有分支上的许多提交，在那里你可以通过一些测试。
3/ 您多久推送一次更改（或提交拉取请求或类似请求）？
发布是另一回事，应该使用“清晰”的历史记录（连贯的合并，表示编译并通过一些测试的内容）。
您发布的分支应该是历史永远不会重写、始终更新的分支。
出版物的速度取决于偏远分支的性质和拉动该分支的人口的性质。例如，如果是为另一个团队，你可以经常推动。如果是针对全系统的集成测试团队，你推送的频率会少很多。
4/您如何开发复杂的功能/进行需要触及很多地方的复杂重构？无法构建的“私人提交”是否可以？完成后，您是将它们也推送到主存储库，还是在推送之前将所有更改捆绑到单个变更集中？
参见 1. 和 2.：首先在您自己的私有分支中打补丁，然后在官方（已发布）补丁分支上重新组织您的提交。如果补丁涉及多个不同的“活动”（或错误修复），则一次提交并不总是最佳选择。
【讨论】：
我会非常非常频繁地对我的 DVCS（我自己的主题或任务分支）进行更改，这样我不仅可以将其用于“交付更改”，还可以在我工作时帮助我：比如“为什么这样5 分钟前还在工作，现在不再工作了？”如果你经常提交，你可以运行一个 diff。
另外，我发现一个非常非常好的技术是使用它来“自文档重构”。让我解释一下：如果您必须对主题分支进行大的重构，然后从整体上查看更改（修改了一组不错的文件），您可能会迷失方向。但是，假设您检查每个“中间步骤”并用评论记录它，那么您正在创建某种您自己的更改的“电影”，以帮助描述您所做的事情！对审阅者来说是巨大的。
【讨论】：
我承诺很多；添加功能甚至重新格式化我的来源时。
我使用 git 并在非共享分支上完成大部分工作。当我添加了足够多的小更改（算作一个块）时，我使用git rebase 将较小的相关更改收集到更大的块中并将其提交到主分支。
这样，我拥有已提交代码的所有优点，我可以向后或向前输入，但我不必犯下所有错误，也不必回溯到主要历史记录。
【讨论】：
您提交的频率和时间是多少？
非常频繁。如果我所做的更改有效并构成了一个不错的补丁，则可能在一小时内多达几次。或者可能是每隔几个小时，这取决于我是花更长时间调试东西，还是尝试有风险的更改。
只有在正确构建时才提交更改吗？
是的，几乎总是如此。我想不出有理由签入未正确构建的代码。但是，您可能有很多原因可以签入未正确运行的代码（在分支中）。
您多久和何时推送更改（或提交拉取请求或类似请求）？
通常仅当功能完成并准备好进行集成测试时。这意味着它已经通过了单元测试和其他相关测试，并且代码/补丁足够干净，我认为它可以进行审查了。
您如何开发复杂的功能/进行需要触及很多地方的复杂重构？无法构建的“私人提交”是否可以？完成后，您是将它们也推送到主存储库，还是在推送之前将所有更改捆绑到单个变更集中？
我将为该功能创建一个命名分支（它可以跨设计文档和问题跟踪系统进行跟踪）。作为中间步骤，不构建的提交只会在私有分支上真正可行，但仍然是例外的。目前，我没有将整个功能分支重新设置为基础并将其合并到一个单一的变更集中，尽管这是我将来考虑做的事情。只有在适当的测试全部通过时才会推送更改。
【讨论】：
我关注这种flow
alt text http://img121.imageshack.us/img121/3272/versioncontrolsysbestpr.png
(Here is the original image url)
我想这说明了一切。基本上我会在实现完整的工作用例/用户故事（取决于您的软件过程）后进行签入。最重要的事情是你签入在它们编译的意义上工作的东西。永远不要break the build！
在每个用户故事/用例之后进行提交的好处是您可以更好地跟踪过去的版本并且撤消更改更容易。
【讨论】：