分支管理

  少于1分钟  

简要概述

高效的持续交付体系，必须需要一个合适的代码分支管理策略，主要有：主干开发、特性分支开发。

只能根据不通的业务场景选择最适合的策略。

主干开发

开发者在主分支提交代码，发布版本时创建版本发布分支。

优点：

1. 集成频繁效率高；
2. 无需在多个分支之间切；
3. 仅包含：主分支、版本分支；

缺点：

1. 可能出现某个人的代码失误而影响全局；
2. 需要在代码运行期间使用特性切换加速开发；

特性分支开发

需要新增特性时，开发者从主干分支克隆特性分支，仅允许在该分支直接提交代码，待功能完成之后合并至主分支，常见的模型有：git flow、github flow、gitlab flow 三种模型。

Git Flow

该模型是在2010年构想出来的，在这十几年里，已经被许多软件团队使用，以至于部分开发者将其视为某种标准。

在使用会涉及到较繁琐的流程，很多团队新人还需额外时间学习才能融入业务开发，反而降低了效率。

分支功能描述：

名称	功能	生命周期	代码稳定	权限
main	主分支	长期	是	仅允许开发负责人且只能从 release 分支合并，tag 只能从 main 分支标记
develop	开发分支	长期	是	不允许直接提交，只能由开发负责人且只能从 feature 分支合并
release-X.Y	发布分支	长期	是	不允许直接提交，仅允许从 develop 分支合并
feature-XYZ	功能分支	合并后删除	否	开发可直接提交代码，必须从 develop 分支创建出来
hotfix-XYZ	补丁分支	合并后删除	否	开发可直接提交代码，比较急的异常，直接从 main 分支创建，完成后必须合并至 main 与 develop 分支

查看分支流程。

查看规范出处。

GitHub Flow

仅包含主分支与特性分支。

相比 Git Flow 简化了流程，开发者接收需求并创建独立的特性分支，完成后则发起 “Pull requests” 请求合并，待在其他人审阅并签署确认后由专人合并到主分支，最后删除特性分支。

名称	功能	生命周期	代码稳定	权限
main	主分支	长期	是	不允许直接提交代码，仅允许负责人合并来自其他分支
feat-X	特性分支	合并后删除	否	由开发人员控制，必须包含完整的文档与测试案例

查看分支流程。

查看规范出处。

GitLab Flow

https://docs.gitlab.com/ee/topics/gitlab_flow.html

---