一、分支说明
1、分支列表
序号 | 分支名称 | 分支描述 | 环境 | 可访问 |
1 | master | 主分支（生产分支） | PRO | 是 |
2 | develop | 开发分支 | FAT | 是 |
3 | feature | 功能分支 | DEV | 否 |
5 | release | 发布分支 | UAT | 是 |
6 | hotfix | Bug修复分支 | DEV | 否 |
7 | xxx-ZhangSan | 个人开发分支 | DEV | 是 |
说明：
dev （Development environment） ： 开发环境，外部用户无法访问，开发人员使用，版本变动很大。
sit (System Integration Test ) ： 系统集成测试，开发人员自己测试流程是否走通。
test ：测试环境，外部用户无法访问，专门给测试人员使用的，版本相对稳定。
fat (Feature Acceptance Test environment) ： 功能验收测试环境，用于软件测试者测试使用
uat (User Acceptance Test environment) ： 用户验收测试环境，用于生产环境下的软件测试者测试使用。
pre ：灰度环境，外部用户可以访问，但是服务器配置相对低，其它和生产一样，外部用户可以访问，版本发布初期，正式版本发布前。
pro（Production environment）：生产环境，面向外部用户的环境，正式环境，连接上互联网即可访问。
二、分支描述
Master：
master 为主分支，用于部署到正式环境（PRO），一般由 release 或 hotfix 分支合并，任何情况下不允许直接在 master 分支上修改代码。
通常情况下 master 分支是受保护的（Protected）。master 分支保存的是稳定的已发布到线上的代码，会使用 tag 来记录发布的版本（tag命名为：tag + “-” + “版本号”）。master 分支是不允许提交代码，只能将代码合并（merge）到 master。在蓝绿部署的情况下，绿色部署环境需要部署此分支代码。
Develop：
开发分支，从 master 创建。develop分支的代码是通过feature分支合并而来, 通常情况下不会在 develop 上进行开发，因为不能确定这些是否需要上线（或者说无法确定在哪次迭代上线）。
develop 为测试分支，用于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发。
一定是满足测试的代码才能往上面合并或提交。
Feature：
继承分支：dev
合并分支：dev
功能分支，从 develop 创建。feature 分支是用来开发新功能的，通常情况下新功能开发完毕后会合并的 develop。
需求开发分支，一旦该需求上线，便将其删除。
Release：
继承分支：dev, hotfix, bugfix
合并分支：master
预上线分支，用于部署到预上线环境（UAT），始终保持与 master 分支一致，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。
从 develop 创建, 当一次迭代的功能开发并自测完成后，就可以创建发布分支。
该分支通常用于测试，不能在该分支上完成除Bug 修复外的其他工作。
测试完成后，需要将 release 分支合并到 master 进行发布。发布完成后在 master 打上 tag 记录此次发布的版本。在蓝绿部署的情况下，蓝色部署环境需要部署此分支代码。
Bugfix：
预发布环境修复分支，从 release 创建。
基于 release 分支上对应的 tag 处创建新的 bugfix 分支，用来修复 bug, 修复完成后，再合并到 release 分支，一旦修复上线，便将其删除。
Hotfix：
线上紧急修复分支，从 master 创建。
基于 master 分支上对应的 tag 处创建新的 hotfix 分支，用来修复 bug, 修复完成后，再合并到 release 分支，一旦修复上线，便将其删除。
通常情况下，紧急修复的发布相对简单，在 Bug 修复并测试完成后，可直接合并到 master 进行发布（注意：如果在蓝绿部署的情况下，需要将bug修复之后的代码重新打包，并部署到蓝色环境下等待测试通过后，再将代码合并到master上）。发布完成后在 master打上 tag 记录此次发布的版本，并将 hotfix 合并到 develop。
Master、develop、release分支上严禁提交代码,只支持代码合并。
三、命名规范
3.1 命名注意事项
分支命名不能包含中文，英文不好可以用全拼。（中文在某些操作系统会乱码，而且对命令行操作、自动化脚本都不友好。）
个人分支以branch- 开头，例如：branch-lisi
标准产品的其它分支命名如上
定制产品的所有分支命名，以定制简称开头，例如：icbc-master,icbc-release,icbc-develop,icbc-lisi等等
bug修复分支命名规则 hotfix-bug序号
3.2 各分支命名规范
主分支（master）
开发分支（develop)
功能分支（feature)：feature-模块名字，例如：feature-login
线上修复分支（hotfix)： hot?x-v版本号-修复功能点简要描述或模块名称
预发布修复分支（bugfix)： bugfix-v版本号-修复功能点简要描述或模块名称
预发布分支（release)：release分支打tag: release-版本号或日期，例如: release-v1.2.112, 或者 release-20220801
四、开发流程
4.1 多人协作开发分支使用流程
在多人协作开发的情况下，所有分支需要全部上传到云仓库。
Master分支用来部署生产环境，release分支用来部署预发布环境。
Master、develop、release分支上严禁提交代码,只支持代码合并。
当生产环境发生紧急bug时，基于master分支上相应tag创建hotfix分支：hotfix-日期(版本)。 bug修复后将分支合并到release分支，并基于release分支打包发布到预发布环境，待测试通过后再将代码合并到master,feature及develop分支上，然后并删除此hotfix分支。
当预发布环境产生bug时，基于release分支上相应tag创建bugfix分支：bugfix-日期(版本)。 bug修复后将分支合并到release分支，并基于release分支打包发布到预发布环境，待测试通过后再将代码合并到feature及develop分支上，然后并删除此bugfix分支。
4.2 单人开发分支使用流程
master、release分支需要上传到云仓库
feature分支只在本地保存即可(可选)。
Master分支用来部署生产环境，release分支用来部署预发布环境。
生产环境Master分支上严禁提交代码,只支持代码合并。
当生产环境发生紧急bug时，基于master分支上相应tag创建hotfix分支：hotfix-日期(版本)。 bug修复后将分支合并到release分支，并基于release分支打包发布到预发布环境，待测试通过后再将代码合并到master分支上，然后删除相应hotfix分支。
当预发布环境产生bug时，基于release分支上相应tag创建bugfix分支：bugfix-日期(版本)。 bug修复后将分支合并到release分支，并基于release分支打包发布到预发布环境，待测试通过后再将代码合并到feature分支上，然后删除相应bugfix分支。