原文地址 https://paulhammant.com/2013/04/05/what-is-trunk-based-development
什么是基于主干开发（简称TBD）？
什么是TBD？
它是一个软件开发的分支模型。历史上，它也被称为“主线/mainline”(见下文)。 它需要更多的专注和严格，而不是(在共享的源代码控制服务器上)建立一个分支来满足一时的需要。虽然您可以在不进行持续集成(CI)的情况下完成，就像许多开源项目所做的那样，但是对于企业开发来说，您必须将CI连接到主干，强制执行“提交是好的”的多个方面。 在本文中，我没有提到开发人员在他们自己的工作站上如何通过“本地”分支来适应他们的逐小时活动。这都是关于共享仓库的，在这里，多个开发人员集成/合并他们的日常工作以达到更好的效果:）
基于主干开发(TBD)是所有开发人员(针对特定的可部署单元)在源代码控制下提交到一个共享分支的地方。这个分支通常被称为主干，甚至可能被命名为“主干/trunk”。开发人员可以在他们自己的开发工作站中进行一些多分支开发(比如使用Git)，但是当他们通过更改或bug修复“完成”时，应该返回到共享主干。如果它不在那里，那就不算“完成”——注意那个小谎言。请参阅下面关于pull-requests的部分。 开发人员不允许在共享位置创建发布分支。只有发布工程师才会致力于这些发布分支，并真正创建每个发布分支。如果有意愿，他们也可以挑选个人向该分支作出承诺。在一个版本被另一个版本取代之后，发布分支很可能被删除。 主干作为一个模型，已经使用了大约20年。最初是由开源社区推动的，但在“企业级”中，当ClearCase(和其他人)发布其他分支模型成为主流时，情况就不那么乐观了。谷歌和Facebook，今天，实践TBD风格的分支模型。如果不完全正确，那就足够接近。无论是谷歌还是Facebook都公开了他们TBD的使用情况，它的市场份额都在不断增长。
但是这里有分支!
是的，有这种情况。但是关于发布。“发布分支”是策略。发布分支在被另一个发布分支取代之前会存在很短的时间，它在创建时从主干中获取所有内容。就合并而言，只支持从主干到发布分支的遴选cherry-pick。对于许多企业，只会合并错误修复。对于Facebook(他们每周从发行分支上进行10次直播)来说，如果利益相关者优先考虑的话，增强功能的合并也会发生。
几乎所有人都同意，bug是固定在主干上并合并到发布分支上的，而不是固定在发布分支上并合并到主干上的。通常只有很少一部分人可以提交到发布分支。
Pull-Requests 还是分支!
好的，所以GitHub率先将pull-request作为开发工作流。这与TBD相当兼容，因为一个特性/任务是在不在主干/主服务器上的位置进行编组的，但可以快速完成。通常情况下，代码审查发生在那里，CI会自动权衡PR分支是否有资格合并到主干/主分支。如果一切正常，PR被合并到主/主干中，然后删除，留下一个平滑的主干/主时间轴。当然，稍后作为pull-request主题的特性/任务分支应该是一个人或一对分支，并且寿命很短(比如一天)。也有一些变体——“fork”和原始的简单分支都是很好的pull-request选择。只有代码仓库读写权限指南应该使用。
开发的义务
开发人员不会用任何提交破坏构建。这需要很多规则，也许这也是为什么谷歌和Facebook的诱导程序对于开发者来说是冗长的。回滚/恢复提交是一种防止由此造成损害(损失时间)的策略。更复杂的公司将使用预提交验证。开发人员养成了这样的习惯:通过同步主干的最新版本，从根本上/从头构建，再次检查它们的功能变化，然后提交，来证明提交是好的。在早期，包括在ThoughtWorks中，开发人员有一个“标记”来证明他们并没有破坏构建——在他们进行验证的过程中，没有人能够控制鸡。橡胶鸡已经被使用了十多年，但是任何东西都可以(感谢Jez的链接)。
持续集成CI
像Jenkins这样的持续集成会参与到这个提交中，并通过构建管道构建、测试、部署、测试等等。它可能会检测到故障，这很可能是因为开发人员没有证明他们的提交或执行令牌操作。另一个问题可能是开发人员在提交之前没有添加新的源文件。这很容易/很快就可以补救，而且“前滚”也可以。
需要“太长时间”才能完成的更改
开发人员使用一种称为分支抽象(BbA)的技术来确保他们能够在更长的时间内完成更复杂的更改。我已经写过很多次了。Martin Fowler强调了这一点，Jez Humble也写过同样的文章。它减轻的风险是分支机构的增加，以及那些“临时”分支机构没有按照人们希望的时间表完成工作。
My own case studies
From 2005, a move from crazy branching towards TBD (a US FX trading bank).
主干开发回顾
Quick reminder of what TBD is: ● 开发提交到一个单独的主干 ● 发布工程师 (or 编译员工) 创建分支, 并且多多少少遴选到分支 ○ 只有一个缺陷不能在树干修复, 才许可给在发布分支修复,并择遴选回主干。 如果你用到了发布分支的概念，那就值得记住: ● 主干开发意味着普通的开发人员承诺不提交到发布分支. ● 主干开发意味着你要删除旧的发布分支,而不是合并回主干
什么绝对不是TBD
开发者提交到多个分支
包含相同源文件的分支。参考BbA上面-你应该这样做。高级开发人员通常会声称他们有一个特殊的案例，并且希望在一个分支上完成。问题在于共享源控制服务器上的分支的增加，它们的“临时”生命期的长度，以及当有许多开发人员和许多提交到某个地方时合并的困难。 Branches containing the same source files, that is. Refer BbA above - you should be doing it. Often senior devs would claim they have a special case, and want to do it on a branch. The pitfall is the proliferation of branches on the shared source-control server, the length of their ‘temporary’ life, and the difficulty of merging when there are lots of developers and lots of commits to one place or another. 即使是喜欢树干概念的人也会反复讨论这一方面的问题。我将在沙子上画一条线，并且说你不应该为特性(在那个共享仓库上)创建分支，不管它们需要多长时间，不管它们是否超过了发布日期。你应该做BbA。
不在单一分支开启一个持续集成管道
当然，作为个人实践，您可以防止破坏，许多开源团队会认为没有CI是好的。但对于拥有数十名开发人员的企业土地，您需要彻底的CI。
手动维护依赖版本号
可以用版本化的方式表示可构建组件的依赖关系。 例如，Log4J目前是1.2.17，由Apache维护。你不会把他们的资源拉进你的资源控制。您将依赖于一个二进制文件，并为您自己的构建文件烘焙版本号(在源代码控制下)。 对于您自己的东西，它可能是在CI的不同阶段构建的，您不应该为特定的构建指定版本号。借鉴Maven的习惯用法，您应该依赖于CI下的移动目标。说“OurCommonThings-1.1-SNAPSHOT”，但要确保你是在“正确”的CI构建阶段构建的。您不打算这样做，但是如果您不使用编译并使用最新版本的everything进行测试，您就不能持续地进行集成。
CI管道中更核心的实现将使用我上面建议的有争议的“1.1-SNAPSHOT”之外的其他东西。It(以及Maven本身)在企业开发中是一个有争议的问题。对于颠覆或强制安装，存储库修订号可以是您使用的——“1.1-12345”。或者，构建号可能很流行(所有CI工具都可以为它们执行的脚本提供一个构建号)。
不在root下持续集成
在常规配置中，CI应该从头构建所有内容，而不是依赖于之前构建的任何内容。一些更复杂的CI基础设施(比如ThoughtWorks Studios的Go)拥有一种更可证明的/指纹的方式，可以使用预构建块进行战术上的操作，但常规安装应该从零开始(尽可能快地)。
基于主干开发是“一切最新版本”的另一个变体。
连续版本的并发开发
有些企业同时处理一系列发行版。他们打算使用运行时切换来进行暗部署，但也可能在生成的二进制文件中使用构建时切换到子集功能，这取决于他们想在CI阶段测试什么。它们可能有多个CI管道用于同一主干，这证明“amazon_one_click=true”和“amazon_one_click=false”交替构建并通过测试。这两个失败中的任何一个仍然是提交失败，并且可能发生回滚/恢复。
您只需要为您希望实时发布的版本设置不同排列的切换管道。如果“管理”取消了一个版本的特性(由一个开关激活)，或者重新排列版本，那么您可以尽快重新配置CI管道。CI很快就澄清了“重新规划”的成本和时间影响，以及由此导致的每个主干的传递/失败视图。你永远不会去测试不合理的切换排列。
顺便说一句，极限编程社区正确地指出，连续发行版的连续开发更可取。
名不副实
mianline是另一回事
好的，传统意义上的“mainline”是trunk的同义词，对于基于主干开发的人一直使用“主线”来描述这一点。问题是“mianline”从1993年开始也被ClearCase社区使用，它指的是一种浪费和延迟的分支模式，如下所示: 
这也是一个“迟到的”的集成设计，而TBD是“最早”的集成流程，这是开发过程中成本降低的关键概念之一，也是最大的助推器。这个分支模型的另一个事实是，挂起发布分支的分支，这些分支应该是临时的。
所有，总结，mianline对于很多软件开发人员来说意味着别的东西。
功能切换
最近我听说人们把TBD称为“功能切换”。马丁•福勒(Martin Fowler)将这种长期存在的做法命名为该行业。它经常与TBD一起使用，但不是必须的。它可以与任何分支模式一起使用，而且可能与开发软件服务并将其投入使用一样古老。
在之前的一个客户端中，我们也谈到了构建时切换。对于maven来说，这些配置文件是这样的:
# with amazon one click
mvn -p amazon_one_click install
# without amazon one click
mvn install
因此，对于该客户端来说，运行时的toggles与构建时的toggles (Maven配置文件)不同，当然有些是两者兼而有之。如前所述，CI管道将启动commit以实现合理的切换排列。
持续发布 (部署)
这是简单的TBD和CI用法的改进。Jez有一本很有名的书，它是必不可少的阅读材料。
感想…
Jez Humble勘误, 有一句很好的引言“分支不是问题，合并才是问题”(这是TBD试图解决的一个问题的一种说法)
更新
June 30th, 2016 - We smile on Pull Requests, of course.
729
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
