主干开发 VS 分支开发

主干开发&分支开发

主干开发往小了说，是版本管理的一种方式。往大了说，它是产品发布、研发团队间协作、服务器测试环境管理等相关措施配合起来才能实现的一种交付方式，更确切的我们可以称之为主干开发 - 分支发布的产品交付模式。
我们一般把Trunk（Master）称之为主干，Branch称之为分支，当然分支还可以sub-Branch，但是Trunk永远只有一个。对应线上的版本，我们用称之为发布分支的Release来管理。Release分支上永远是稳定版本。
对于主干开发来说，代码所经历的过程是从开发人员的PC到Trunk到Branch最后到Release 的过程。根据代码交付的路径不同，另一种交付模式“分支开发”，分支开发的过程则是从开发人员的PC到Branch到Trunk最后到Release的过程。正是这中间两步的差异，造就了两个开发模式之间的天壤之别，而彼此的优缺点也大不相同。
从代码的路径我们可以看到多个开发人员的代码的汇聚点在Trunk上，这就是主干开发第一个显著的特点，即所有开发人员的代码都是基于同一套代码进行开发。开发人员每天都在这个主干上签入签出他们的代码，不断地集成，测试和修复，直到计划的发布的功能被实现的时候，再从这个版本打一个Tag，然后拉一个测试分支发布到系统测试环境。系统测试人员对测试分支进行系统测试。而同时开发人员则继续在主干上开发新的功能。系统测试环境发现的缺陷，会在系统测试分支上被修复，修复后立刻同步到Trunk上。经过系统测试的版本接下来会发布到生产环境。而此时开发人员可能正在准备第二个版本的系统测试交付。

主干开发图示
**

分支开发图示

为什么主干开发将会成为主流？
主干开发模式极大消除了系统集成风险，让原本痛苦的系统集成，在开发阶段的时候就无时无刻的发生。这种模式把敏捷的持续集成实践方法发挥到了极致。这就使得系统的潜在可交付产品（Potential Shippable Product）的成功率大大被提高了。与Scrum中的迭代潜在可交付产品略有不同的是，Scrum的迭代交付是在迭代内完整功能的交付，如果不能在本迭代做完的功能，则建议拆分地端到端更为细小或者放入下一个迭代来完成。直到可交付的功能可以满足一定业务需要时，才进行系统测试和发布。当然在迭代过程中进行系统测试也不是坏事，只要有自动化或者人力保障（关于迭代内回归测试对于刚转型的scrum团队来说，永远是抹不掉的痛）。因此Scrum的发布周期和迭代长度往往是1：1或者1:N的关系。

回到主干开发的PSP。主干开发将要交付的版本并不包含所有完整，开发人员需要通过功能开关来屏蔽不希望用户看到的功能。只有那些实现了完整业务的功能才会被展现在用户面前。这样做看上去很不“安全“，但是却解决了功能不能拆分或不能组装而无法完整业务发布、不能发布的问题。正因为这样，主干开就发变得“准”时时可发布。它可选择的发布窗口期可以不再是迭代的倍数，而是在迭代内也可以，甚至有团队做到每天一发布。这种发布机制正式以快为重要特征的互联网产品的所需要的。所以这种发布模式也必然是未来互联网公司的主流模式。

主干开发与分支开发的优缺点

主干开发的具体形式是所有的开发人员在一个主干上进行代码的潜入签出。其最大的好处在于在复杂环境中，让风险提前被防范和消除。不过这种模式也有其局限性，特别是主干开发并不能很好地支持客制化产品的开发。对于需要客制化的产品，需要分为核心功能和定制功能。核心功能天生适合主干开发。而对于定制功能（最简单的如：产品首页Logo），则可通过配置的方式解决。简单的说，我们希望的为每个定制产品增加一条配置信息，而不是一个分支产品。通过配置避免版本的分裂，这是最合理的分支方案。虽然随着产品的发展，这类型的产品的定制化会越来越严重，这就迫使产品经理需要考虑是否需要这么多定制化，是否将某些定制化整合为核心功能，是否抛弃某些定制化的维护。这也是产品策略需要决定的方向之一。

主干开发优点：发布频率高 - 可以做到一周多次 团队专注度高 - 团队只关注当前版本的内容的开发和集成，没有分支同步等困扰 系统集成风险低 - 在开发阶段解决集成问题 统一的测试环境管理。

主干开发缺点：发布频率受人数影响 依赖功能开关 不适合定制化产品开发

主干开发的前提条件和注意事项

很多团队在尝试主干开发，但是并不能很好地执行，因为在尝试主干开发之前，需要认真思考一些东西，我们需要主干开放么？ 主干开发能帮我们解决现在的问题么？
同时也需要需考虑在做主干开发之前，是否满足主干开发的其前提条件，以及在执行过程中时刻关注注意事项。

前提：团队理解主干开发的优缺点 团队并掌握持续集成代码管理步骤 需要移除多版本并行问题，否则无法基于一个主干版本进行开发 主产品，非分支产品开发。
需要注意：团队力争主干上的内容的稳定性，这样才可使主干随时可用 大部分开发人员在主干上进行开发，用分支方式解决实际开发过程中的一些问题 持续集成要不停的验证主干和发布分支的稳定性和正确性。对于提交测试以后，要把对于主干问题，放到发布分支上进行验证 生产上的内容必须是正常执行的，如果出现问题，先回滚到上一个主干发布的版本，然后按照按照特定的修复通道进行修复

总之，主干开发未来肯定是互联网产品、单一产品的主流开发模式。从分支开发转型到主干开发，可能让你所在的团队，组织的开发方式有很大的改变。但是这种改变一定是值得的。曾经有家公司在2个月不能交付的情况下，采用主干开发1个多月后实现了每星期两次交付的频率。这对以快为生命的互联网企业来说，是重新获得生机最有效方式。互联网企业三大支柱是：业务的不断创新、研发的快速交付、精确的运营反馈。少一个支点就不会走的很稳。而敏捷或主干开发是研发快速交付的有效方案