我的团队最近决定不使用大多数颠覆存储库布局典型的“trunk”分支。我们发现，在任何特定的时刻，总会有一个特定的分支在传统角色中起作用，主干将在其他存储库中保存。也就是说，我们总是有一个编号最高的分支，代表我们正在开发的下一个版本。因此合并到主干简直是多余的，所以我们摆脱了主干。
有没有其他人这样做？
如果是这样，你有没有注意到任何利弊？
即使你的团队没有这样做，有没有人对这种布局有任何想法？
答案 0 :(得分：29)
你在谈论Promotional Model - Perforce的论文强调了它的问题 - 传达不断变化的代码行角色和分支机构之间的工作。
扩展我对所列问题的看法：
1）改变代码行政策：
每个代码行都有一个策略，无论是写下来还是形式化，还是完全隐含在开发人员的头脑中。它定义了例如：
使用主干方法，策略保持不变，因此更易于记录，这使得它们更容易通信（在更大的团队中更重要）。
e.g。外线：
版本分支：
标签分支：
开发者的私人分支：
如果您有促销模型，那么在主要开发阶段就有一个策略，然后在准备发布时更改策略时必须告诉所有人，然后在发布行时再告诉其他策略（代码行）。 / p>
促销模型很容易进入，它直接映射到非源控制的工作方式。但是一旦你开始接触大型团队，它就会受到伤害。
如果你看看Linux内核开发，你可以看到Promotional模型和Trunk模型之间的紧张关系：Linus的树是促销 - 它经历了合并窗口和rc /稳定期之间的循环。但Linux-next和-mm如雨后春笋般涌现，以提供更多的干线。
无论如何，分布式SCM / VCS有些不同，不必将策略分发给所有开发人员，因为每个开发都有自己的树，并在需要时进行更改。开源项目遇到的问题是，他们不能强迫人们在从主干分支后进行稳定释放的苦差事。因此，促销模式作为强制稳定工作的一种方式更为重要，而不仅仅是处理功能。
2）搬家工作：
当他正在处理的行的策略仅更改为错误修复时，开发人员可能正在处理某个功能，他现在需要将其工作副本切换到不同的代码行。 根据使用的SCM系统，这可能是从易到难的任何地方。 如果开发人员正在使用trunk，则不会发生此问题，因为他们的工作始终是中继。如果开发人员在私人或功能分支上，那么他们的工作将只会影响主干（和发布）。
如果某个功能已经签入，但是从当前版本的版本中延迟，则必须确定如何删除它。这个问题仍然存在于主干模型中，但可能更容易解决 - 从发布版本的主干中挑选东西。 这是功能分支帮助的地方 - 但它们具有集成成本。
答案 1 :(得分：8)
Perforce论文的问题在于它拒绝了促销模式而没有提到主要优势，减少了合并开销。事实上，该论文错误地指出“主线模型”强加“没有额外的行政管理费用”，这是一个荒谬的主张。 “始终合并到主干”模型意味着 - 你有每个人必须合并的开销。如果你有以下情况（我们有），这是毫无意义的开销：
a）一个小团队（5到7名开发人员）都在彼此的呼喊距离内。当我们需要建立分支时，沟通是不成问题的
和
b）一个代码库，其中实际上只有两个主要分支 - 一个生产分支和“开发中的下一个”。也许在蓝色的月亮中我们有3个。
我想我的观点是 - 这是一种情境化的事情。说“促销模式有问题”就像是说“从不使用OR / M”。这取决于你的环境。
答案 2 :(得分：1)
Subversion允许两种方法。行李箱不是必需品，而是惯例。如果你拥有它，一些工具更容易工作（例如Git的迁移工具）。如果你没有，你必须手动做一些事情，但我想不出你在日常工作中会注意到的事情。
答案 3 :(得分：1)
我最近开始研究一个在subversion存储库上的项目。创建存储库的人没有遵循任何特定的布局 - 他们只是将所有内容都填充到存储库的根目录中（没有trunk /，没有分支/，当然也没有标记/）。我想创建一个分支来处理其他东西，但是想知道在不遵循正确布局的subversion存储库上做这件事是多么困难。
答案 4 :(得分：0)
我们这样做 - 有点儿。我们不使用主干，但为每个项目版本创建一个新分支。这个'标记'分支是每个版本的主干，我们通过将更改合并到旧版本来反向错误修正。
它适用于我们，但我们的项目中确实有很多子项目。
答案 5 :(得分：0)
IME，在某些环境中，主干是交换修复和更改的好地方。也就是说，每个人都将他们的修复程序合并到主干，并且每个人都从主干中合并其他人的修复。我们发现在许多独立项目之间共享大量代码并且所有这些项目都对共享代码做出贡献的环境中非常有用。
但您的环境可能会有所不同。