源代码控制策略

Question

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

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

Answer 1

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

Answer 2

我最喜欢的政策是“没有颠覆承诺不引用门票+自动Trac的评论对每一个提交”：http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook

Answer 3

我已经取得了巨大的使用书Practical Perforce的。虽然你可能没有使用Perforce，但我认为第7章（软件的演变）和第8章（基本代码管理）可能非常有用。你可以在Google Books上浏览它们。

Perforce在这个问题上也有很多很棒的文章。 Software Life-Cycle Modeling写道政策。
Perforce complete technical documentation。

而且，不，我没有为Perforce工作。

祝你好运， 托马斯

Answer 4

没有空提交信息。

Answer 5

提交每更改而不是每个文件。

这具有以下优点：

• 以后，您可以看到为什么这一行已在此确切的文件被更改（啊哈，这是对错误＃123 Bug修复）。如果您提交每个文件，则提交消息往往会描述文件中所做的更改 - 无论如何，您都可以通过diff查看。如果您提交per-change，那么提交消息往往可以解释为什么首先完成更改。
• 恢复或合并更改/错误修复要容易得多。
• 当你清楚地关注你正在工作的单个bug /特性/改变时，它有助于更​​好地组织你的工作。你完成后就提交。

有些人认为这个政策会产生更多的承诺，但从我的经验来看，您最终获得的承诺更少。例如，您正在进行影响50个文件的重构。重构后，您只需提交一条消息“重构xyz子系统”。

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

Answer 6

请勿签入/提交任何破坏构建的更改。

Answer 7

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

• 成功检查（编译，测试，审查，FxCop'ed等）
• 原子（应该只包含一个逻辑变化，FE单一错误修正，重构等）
• 非冗余的（未使用的代码应该加入，不要犯注释代码，将其删除，不小心犯格式的变化等）
• 正确和全面评价
• 匹配的电流开发阶段（例如，不应该重构b e允许在版本支持分支中）
• 尽可能小以匹配先前的规则。

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

Answer 8

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

我们正在使用这种策略，使躯干稳定，使开发人员能够做什么，他们需要自己的分支机构。

有一些问题，因为颠覆它不能处理Cyclic merges，但它可以通过删除开发分支每个重返社会后回主干工作围绕（无关其他版本控制系统）