TBD主干开发介绍

[gnipbao]

主干开发是一套代码分支管理策略，开发人员之间通过约定向被指定为主干的分支提交代码，以此抵抗因为长期存在的多分支导致的开发压力。 此举可避免分支合并的困扰，保证随时拥有可发布的版本。

在介绍主干开发前先来对比一下目前的分支管理策略。

Git Flow

简介

Git分支配置的规则，也是实现该规则的工具 最完整的体系。

特点

1. 两个长期分支：master和develop
2. 三个短期分支：feature(功能)、hotfix(补丁)、release(预发)
3. master分支用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的发布版；develop用于日常开发，存放最新的开发版。
4. 短期存在的分支一旦完成开发，它们就会被合并进develop或master，然后被删除。
   长期分支：
   master（主分支）：保存最新已发布版本基线的分支。
   develop 分支（开发分支）：对开发的功能进行集成的分支。
   短期分支：
   feature 分支（功能分支）：开发者进行功能开发的分支。从Develop分支上面分出来的。开发完成后，要再并入Develop。
   hotfix 分支（补丁分支）：对线上缺陷进行修改工作的分支。从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。
   release 分支（预发分支）：负责版本发布的分支。从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。

优势

1. 提供了相对完备的各种分支，覆盖软件开发过程中的大部分场景。
2. 各个feature之间代码隔离，可以独立开发、测试，分支清晰。

劣势

1. 分支较多时，合并代码时容易存在冲突。
2. 相对复杂，学习成本相对来说会高一些。

应用场景

1. 对产品质量上要求高，发布的版本有较长的维护周期。
2. 需要支持多个版本并且相互独立，同时后续各版本开发。
3. 大规模团队适用。

图解

GitHub Flow

简介

Git Flow 对于大部分开发人员和团队来说，稍微有些复杂，而且没有 GUI 图形页面，只能命令行操作，所以为了更好的解决这些问题，GitHub Flow 应运而生了。

特点

1. 只有一个长期分支master以及各种短期的feature分支。
2. 只要在master分支中的代码一定是可以部署的。
3. 如果想获得反馈或建议，或者愿意合并分支，需要发起一个pull Request。
4. 当 review 或者讨论通过后，代码会合并到目标分支。
5. 一旦合并到 master 分支，应该立即发布。

优势

1. 简单好理解。
2. 对于"持续发布"的产品，可以说是最合适的流程，简化部署，持续交付。

劣势

1. master合并后如果不发布，会造成线上和master不一致。
2. 只有一个主分支，不能部署不同的环境（例如：测试环境，预发环境，正式环境）。

应用场景

1. 持续发布，快速迭代，每次更新，直接部署。
2. 适合中小型项目，开发人员少的项目。

图解

GitLab Flow

简介

结合了Git Flow和GitHub Flow的优点，折中的版本。

特点

1. 拥有三个长期分支master、pre-production、production，其他分支为临时分支。
2. master 分支反映的是部署在集成环境上的代码，pre-production 分支反映的是部署在预发环境的代码，production 分支反映的最新部署在生产环境的代码。
3. 生产环境中出现问题，要先再master分支解决问题，然后提交到pre-production分支验证，最后在确定没有问题的前提下，更新到production分支。

优势

清晰可控，由于修正是在master层面，所以确保所有的提交都是测试环境中通过测试的。

劣势

1. 相对于github flow来说，gitlab flow 更复杂。
2. 当维护较多版本时，会变得像git flow似的比较复杂。

应用场景

需要进行预发布/周期性版本发布的项目。

图解

TBD

简介:

全名Trunk-based development、略称TBD.基于主干开发，所有开发人员都只能在一个开发分支中开发。

特点：

1. 有且仅有一个开发分支，即主干分支。所有改动都发生在主干分支。
2. 发布直接从主干拉发布分支，有许多个发布分支。
3. 主干上进行的修复需要根据缺陷的修复策略，确定是否 cherry pick 到对应版本的发布分支。git cherry-pick命令的作用，就是将指定的提交（commit）应用于其他分支。

优势：

• 避免分支合并的困扰，保证随时拥有可发布的版本
• 主干开发是助力实现 持续集成 和 持续交付 的关键因素。开发团队的成员一天多次地将代码提交到主干分支，满足了持续交付的必要条件。团队的工作在 24 小时内就可以被整合，这保证了代码版本随时处于可发布状态，使得持续交付成为可能。
• 你可以选择直接向主干分支提交代码的方式（适用于小团队）或者采用 MR 的方式，merge approve后可以选择删除特性分支
• 根据团队规模和提交频率， Feature分支可用于合并到主干分支前的CR和持续集成

劣势：

主干分支是所有开发人员公用的，一个开发人员引入的 bug 可能对其他很多人造成影响。

应用场景：

协作能力强的小规模团队。

图解：

CI/CD简介

自动打版本工具

standard-version

参考资料

https://cloud.google.com/solutions/devops/devops-tech-trunk-based-development?hl=zh-cn
https://cn.trunkbaseddevelopment.com/