源代码控制策略

Question

我正在寻找有关不同源代码控制策略的概述。我只是遇到了主线政策，并希望在与团队合作之前更好地了解其他人。

有人可以提供概述链接，甚至可以给我一些政策名称，以便我可以启动谷歌吗？

Answer 1

没有空提交消息。

Answer 2

论文"streamed lines: branching patterns for parallel software development" 是关于分支模式的极好讨论，例如你提到的“主线”模式 - 它以模式的形式列出了选项以及反模式的讨论。其中一位作者是Perforce的Robert Orenstein。

Answer 3

我们在项目中使用了几个实用规则作为提交策略。这些规则有助于我们将每个修订版保持在准备部署状态。我们的规则类似于KDE提交策略，在此处发布：http://techbase.kde.org/Policies/SVN_Commit_Policy。 每次提交都应该（从较高优先级到较低优先级）：

• 成功检查（编译，测试，审核，FxCop'ed等）
• Atomic（应该只包含一个逻辑更改，例如单个错误修正，重构等）
• 非冗余（不应添加未使用的代码，不提交注释代码，删除它，不要意外地进行格式更改等）
• 正确而完整地评论
• 匹配的当前开发阶段（例如，版本支持分支中不允许重构）
• 尽可能小以匹配以前的规则。

我们开发了一个简单的工具SvnCommitChecker，它可以帮助我们在提交到svn之前检查一些这些规则。我计划在不久的将来将它发布到sourceforge上，并附上一篇关于保持良好的svn变化历史的好处的文章。

Answer 4

我很好地使用了这本书Practical Perforce。虽然您可能没有使用Perforce，但我认为第7章（软件如何发展）和第8章（基本代码管理）可能非常有用。您可以在Google Books上浏览它们。

Perforce也有很多关于这个主题的精彩文章。 Software Life-Cycle Modeling撰写有关政策的文章 Perforce完成technical documentation。

而且，不，我不会为Perforce工作。

祝你好运， 托马斯

Answer 5

这两个基本相同：
Version Control for Multiple Agile Teams
Configuration Management Branching Strategy

我们正在使用此策略使主干稳定，并使开发人员能够在分支机构上做任何他们需要的事情。

Subversion存在一些问题，因为它无法处理Cyclic merges，但它可以通过在每次重新集成到主干后删除开发分支来解决（与其他版本控制系统无关）

Answer 6

我最喜欢的政策是“没有参考门票的Subversion提交+每次提交的Auto Trac评论”：http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook

Answer 7

提交每次更改而非每个文件。

这有以下优点：

• 您稍后可以看到为什么在这个确切的文件中更改了这一行（aha，这是bug＃123的bugfix）。如果您提交每个文件，那么提交消息往往会描述在文件中完成的更改 - 无论如何您都可以使用diff查看。如果您提交per-change，那么提交消息往往会解释为什么首先要进行更改。
• 更改或合并更改/错误修正要容易得多。
• 当您明确关注正在运行的单个错误/功能/更改时，它有助于更​​好地组织您的工作。你完成后就会提交。

有些人认为这个策略会产生更多的提交，但根据我的经验，毕竟你的提交次数较少。例如，您正在进行重构，这会影响50个文件。重构后，您只需提交一条消息“Refactored xyz subsystem。”。

对于更大的更改，您应该考虑 dev-branch-per-change 政策。

Answer 8

不要签入/提交任何破坏构建的更改。