21

我的团队最近决定不使用大多数 subversion 存储库布局中典型的“主干”分支。我们发现，在任何给定时刻，总会有一个特定的分支发挥着主干在其他存储库中的传统角色。也就是说，我们总是有一个编号最高的分支，它代表我们正在处理的下一个版本。因此合并到主干是多余的，所以我们摆脱了主干。

外面还有其他人这样做吗？

如果是这样，您是否注意到任何优点/缺点？

即使你的团队不这样做，有人对这个布局有什么想法吗？

4

6 回答 6

29

您正在谈论促销模型 - Perforce 的论文强调了它的问题 - 传达代码行角色的变化以及在分支之间移动工作。

扩展我对所列问题的看法：

1）改变代码行的策略：

每个代码行都有一个策略，无论是写下来并正式化，还是完全隐含在开发人员的脑海中。它定义例如：

  • 谁被允许提交代码行
  • 需要多少测试（例如单元测试是否必须通过、回归测试、完整系统测试）
  • 有多少人必须对更改进行代码审查
  • 允许什么样的改变

使用主干方法，策略保持固定，因此更容易写下来，这使它们更容易沟通（在更大的团队中更重要）。

例如主干：

  • 任何开发者都可以提交
  • 任何改变
  • 单元测试必须通过
  • 提交后的代码审查

版本分支：

  • 唯一的维护开发人员
  • 只有错误修复
  • 单元测试+回归测试
  • 提交前由其他 2 位开发人员进行代码审查

标签分支：

  • 创建后没有提交

开发者的私有分支：

  • 只有开发人员签入
  • 任何改变
  • 仅在合并到主干之前需要测试
  • 合并到主干之前的代码审查

如果你有推广模式，那么你在主开发时有一个策略，那么当你在准备发布时更改策略时必须告诉所有人，然后在该行发布时另一个策略（用于代码行）。

推广模式很容易进入，它直接映射到非源代码控制的工作方式。但是一旦你开始组建大型团队，就会很痛苦。

如果您查看 Linux 内核开发，您会发现 Promotional 模型和 Trunk 模型之间的紧张关系：Linus 的树是 Promotional 的 - 它在合并窗口和 rc/stabilisation 周期之间经历循环。但是 Linux-next 和 -mm 已经出现，以提供更像主干的线路。

无论如何，分布式 SCM/VCS 都有些不同，这些策略不必分发给所有开发人员，因为每个开发人员都有自己的树，并在需要时拉取更改。

开源项目的问题是，在从主干分支之后，它们不能强迫人们做稳定发布的苦差事。因此，提升模型作为一种强制稳定工作的方式更为重要，而不仅仅是在功能上工作。

2）搬家工作：

开发人员可能正在开发一项功能，当他正在处理的行的策略仅更改为错误修复时，他现在需要将他的工作副本切换到不同的代码行。根据所使用的 SCM 系统，这可能很容易，也可能非常困难。如果开发人员在主干上工作，则不会发生此问题，因为他们的工作总是在主干上。如果开发人员在私有或功能分支上，那么他们的工作只会影响到主干（和发布）。

如果某个功能已签入，但与当前版本相比有所延迟，则您必须弄清楚如何删除它。这个问题仍然存在于主干模型中，但可能更容易解决 - 从主干中挑选东西进行发布。这是功能分支提供帮助的地方 - 但它们有集成成本。

于 2009-08-24T15:45:25.137 回答
8

我对 Perforce 论文的问题是它拒绝了促销模型而没有提及主要优势，减少了合并开销。事实上，该论文错误地指出“主线模型”强加了“没有额外的管理开销”，这是一种荒谬的说法。“总是合并到主干”模型意味着——你有每个人都必须合并的开销。如果您有以下情况（我们有），这是毫无意义的开销：

a)一个小团队（5 到 7 名开发人员）都在彼此的喊叫距离之内。当我们需要建立一个分支时，沟通不是问题

和

b)一个代码库，其中实际上只有 2 个主要分支 - 一个生产分支和“开发中的下一个分支”。也许曾经在一个蓝月亮我们有3。

我想我的意思是——这是一个情境问题。说“促销模型有问题”就像说“永远不要使用 OR/M”。这取决于您的环境。

于 2009-08-25T01:36:15.447 回答
1

我最近开始研究一个位于 subversion 存储库上的项目。创建存储库的人并没有遵循任何特定的布局——他们只是将所有内容都塞进了存储库的根目录（没有主干/，没有分支/，当然也没有标签/）。我想创建一个分支来处理其他东西，并为其他东西创建一些标签，但我意识到在不遵循正确布局的 subversion 存储库上这样做是多么困难。

于 2009-08-24T15:53:20.177 回答
1

Subversion 允许这两种方法。树干不是必需品，而是惯例。如果你有它，一些工具会更容易工作（例如 Git 迁移工具）。如果你没有它，你必须手动做一些事情，但我想不出你在日常工作中会注意到的事情。

于 2009-08-24T15:32:53.520 回答
0

IME，在某些环境中，主干是交换修复和更改的好地方。也就是说，每个人都将他们的修复合并到主干，每个人都从主干合并其他人的修复。我们发现这在许多独立项目之间共享大量代码并且所有这些项目都对共享代码做出贡献的环境中非常有用。

不过，您的环境可能会有所不同。

于 2009-08-24T21:32:16.053 回答
0

我们做 - 有点。我们不使用主干，而是为项目的每个版本创建一个新分支。然后，这个“标记”分支是每个版本的主干，我们通过将更改合并到旧版本来支持错误修复。

它对我们很有效，但我们的项目中确实有很多子项目。

于 2009-08-24T15:33:23.160 回答