源代码控制策略答案

【问题标题】：Source code control policy源代码控制策略
【发布时间】：2010-09-12 06:35:27
【问题描述】：

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

谁能提供一个概述链接，或者给我一些政策名称，以便我可以在上面启动谷歌？

【问题讨论】：

【解决方案1】：

我最喜欢的策略是“没有不引用票证的颠覆提交 + 每次提交的 Auto Trac cmets”：http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook

【讨论】：

【解决方案2】：

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

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

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

祝你好运，托马斯

【讨论】：

【解决方案3】：

没有空的提交消息。

【讨论】：

【解决方案4】：

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

这有以下优点：

稍后您可以看到为什么在这个确切的文件中更改了这一行（啊哈，这是错误 #123 的错误修复）。如果您按文件提交，那么提交消息往往会描述文件中所做的更改——无论如何您都可以通过 diff 看到这些更改。如果您按更改提交，那么提交消息往往会首先解释为什么要进行更改。
还原或合并更改/错误修复要容易得多。
它有助于更好地组织您的工作，因为您清楚地专注于您正在处理的单个错误/功能/更改。完成后提交。

有些人认为这个策略会产生更多的提交，但根据我的经验，你得到的提交毕竟更少。例如，您正在进行影响 50 个文件的重构。重构后，您有一个带有消息“重构的 xyz 子系统”的提交。

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

【讨论】：

这会导致大量提交，不是吗？你能说出一个支持这种策略的源代码控制系统吗？我知道的所有系统都只支持按文件提交。
是的，有很多提交。只要它们是真实的 (thedailywtf.com/Articles/Productivity-20.aspx) 这不是问题@Vilmantas Baranauskas 希望确保他可以跟踪个人提交的用途。这是一种权衡。
Subversion 支持它。例如。你在 bug #123 上工作。要修复此错误，您必须更改 10 个文件。完成后，在源代码树的根目录上提交：svn commit -m "Fixed bug #123."。对 10 个文件的修改将作为带有单个消息的单个提交提交。
这并不能解决我看到的问题。假设您处理 Bug #1 并在文件 X 中执行某些操作。现在您必须在修复 Bug #1 的情况下处理 Bug #2。你完成了 Bug #2。你现在怎么能只提交 bug #2 的更改？还是我误解了这个概念或太过分了？
我认为并行处理 2 个错误修复是个坏主意。当然，如果错误 #1 和 #2 相关，则修复它们并提交“修复错误 #1 和 #2：。”

【解决方案5】：

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

【讨论】：

【解决方案6】：

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

【讨论】：

【解决方案7】：

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

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

【讨论】：

【解决方案8】：

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

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

【讨论】：