一般业内的分支管理标准有git-flow、github-flow或者gitlab-flow，优缺点各不相同。但参照京东前端组的经验，这些流程要么太复杂，要么太简单，因此这里提出如下折中方案，建议执行。

分支类型
master分支
release分支
feature分支
hotfix分支

1. Master分支

Master分支始终保持和线上代码一致，方便随时回溯或者进行并行开发。

1. Release分支

在多人开发的时候，多个feature分支或者hotfix分支，先在Release分支上合并和解决冲突，测试通过后，在release分支上发布。

Release分支命名规范：release-v2.1.0

1. Feature分支

开发接到版本需求并开始开发时，从master签出分支，并命名为feature-xxx（譬如feature-cache）；开发在此分支上进行代码开发和测试，测试完成后，合入release分支进行发布。

1. hotfix分支

在正常开发周期中，如果线上程序突然出现bug需要紧急修复，则从master迁出hotfix分支，并命名为hotfix-xxx（xxx一般是bug单号），并在此分支上解决问题并测试。

问题修复完之后，可以直接在hotfix上发布（如果没有其他特性），也可以合并在release分支发布（跟其他特性一起）

开发场景
一、正常版本发布

正常流程：

step 1. 根据版本规划，从master拉取分支release_20200401（表示计划是20200401日发布）

step 2. 开发同学A，根据自己的任务，从master拉取分支feature_A；同理，开发同学B，拉取特性分支feature_B进行开发

step 3. feature_A和feature_B分别开发和测试，相互不影响

step 4. 测试通过之后，feature_A和feature_B分别合入release_20200401分支

step 5. 在release_20200401上进行集成测试

step 6. 测试完成并达到发布要求后，将release_20200401分支合入master

step 7. 确定最终的版本号，并在master打tag，譬如v1.2.0

异常流程：

1. 集成测试过程中的bug修复

在合入release分支之后，如果发现bug需要修复，需要先在feature分支上修复，再合并到release分支。原因是为了避免临时剔除分支时出现操作复杂的问题。

2.发布过程中，临时剔除不符合发布规范的分支

在集成测试阶段，如果发现部分分支不符合规范，可以进行快速剔除，只需要从release分支中revert掉某个feature分支即可。

二、线上bug修复

正常流程：

和“正常版本发布流程”一样，从master上拉取hotfix分支并进行bug修复，修复完成后：

如果有并行release分支，并且此hotfix并不需要紧急发布，则可以合入到release分支，随reelase分支一起发布
如果没有release分支，或者此bug需要紧急修复，则可以直接在hotfix分支上发布
异常流程：

hotfix流程相对简单，一般情况下没有异常情况，如果出现异常情况，随机应变即可。