我应该多久向源代码控制提交一次更改?在每个小特性之后，还是只在大特性之后?
我正在开发一个项目，有一个长期的功能要实现。目前，我在完成每一大块工作后，即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而，我对这种模式感到担忧。在一个富有成效的工作中，我可能会提交10次。鉴于我使用的是Subversion，这些提交会影响整个存储库，所以我想知道做这么多次是否真的是一个好做法?
当前回答
想想看。
(只要你登记的东西是安全的)
其他回答
每当我对编译和运行的代码进行“全面思考”时，我都会签入。这通常会持续15到60分钟。有时它可能会更长，但我总是尝试签入如果我有很多代码更改，我不想在失败的情况下重写。我通常也会确保我的代码被编译，并且在下班回家前检查。
我不会担心提交/签入“太多”。当您不得不重写某些内容时，这真的很糟糕，并且能够以小增量回滚以防万一是很好的。
我喜欢每30-60分钟提交一次更改，只要它编译干净，并且在单元测试中没有回归。
好吧，你可以有自己的分支，你可以随时提交，当你完成你的特性时，你可以将它合并到主干。
关于提交的频率，我是这样想的，如果我的硬盘崩溃了，而我没有提交一些东西，这对我来说有多痛苦-这个东西对我来说大约是2个小时的工作。
当然，我从不提交不能编译的东西。
我遵循开源咒语——尽早提交，经常提交。
基本上，每当我认为我添加了有用的功能(无论多么小)而没有给其他团队成员带来问题时。
这种经常提交的策略在持续集成环境中特别有用，因为它允许针对其他开发工作进行集成测试，从而及早发现问题。
正如其他人所说的，尝试提交一个足够“完整”的逻辑块，它不会妨碍其他开发人员(例如，它构建并通过自动化测试)。
每个开发团队/公司必须为每个分支定义什么是“足够完整”的。例如，你可能有只需要代码来构建的功能分支，也需要代码来通过自动化测试的Trunk，以及表明某些东西已经通过QA测试的标签……或者类似的东西。
我并不是说这是一个好的模式;我只是想指出，如何“完成”取决于你的团队/公司的政策。
