我应该多久向源代码控制提交一次更改?在每个小特性之后，还是只在大特性之后?
我正在开发一个项目，有一个长期的功能要实现。目前，我在完成每一大块工作后，即每一个子特性实现和bug修复后提交。我甚至在发现bug后为某些特性添加了一组新的测试之后才提交。
然而，我对这种模式感到担忧。在一个富有成效的工作中，我可能会提交10次。鉴于我使用的是Subversion，这些提交会影响整个存储库，所以我想知道做这么多次是否真的是一个好做法?
当前回答
正如其他人所说的，尝试提交一个足够“完整”的逻辑块，它不会妨碍其他开发人员(例如，它构建并通过自动化测试)。
每个开发团队/公司必须为每个分支定义什么是“足够完整”的。例如，你可能有只需要代码来构建的功能分支，也需要代码来通过自动化测试的Trunk，以及表明某些东西已经通过QA测试的标签……或者类似的东西。
我并不是说这是一个好的模式;我只是想指出，如何“完成”取决于你的团队/公司的政策。
其他回答
你现在的模式说得通。请记住如何使用这个源代码控制:如果您必须回滚，或者如果您想做一个不同的?在这些情况下，你所描述的块看起来就像是正确的差异:差异将准确地显示在实现bug #(在签入日志中指定)时发生了什么变化，或者确切地显示用于实现特性的新代码是什么。类似地，回滚一次只会触及一个东西。
我使用的经验法则是签入，当签入的文件组可以被单个签入注释覆盖时。
这通常是为了确保签入是原子的，并且注释可以很容易地被其他开发人员消化。
当您的更改影响到具有应用程序范围的配置文件(例如spring上下文文件或struts配置文件)时，情况尤其如此。如果您在签入之前做了几个“组”的更改，它们的影响在配置文件中会重叠，导致两个组彼此合并。
不要提交实际上不起作用的代码。不要将存储库用作备份解决方案。
相反，以自动的方式在本地备份不完整的代码。时间机器会照顾我，还有很多其他平台的免费程序。
我也喜欢在完成一大块工作后做出承诺，通常一天要做好几次。我认为在小提交中比在大提交中更容易看到发生了什么。如果担心提交太多，可以考虑创建一个分支，并在整个特性完成后将其合并回主干。
这里有一篇相关的博客文章:编程的恐惧:尽早检查，经常检查
我遵循开源咒语——尽早提交，经常提交。
基本上，每当我认为我添加了有用的功能(无论多么小)而没有给其他团队成员带来问题时。
这种经常提交的策略在持续集成环境中特别有用，因为它允许针对其他开发工作进行集成测试，从而及早发现问题。
