分支构成
master和develop分支一直存在，且名称不会变化，一般不直接修改这2个分支，由其他分支合并而来。
feature、release、hotfix分别用于功能点开发、优化，特定版本测试，线上问题紧急处理，同一类型的分支会产生多个。
分支划分如下：
- master：与线上版本保持绝对一致；
- develop：开发分支，由下文提到的release、feature、hotfix分支合并过后的代码；
- feature：实际功能点开发分支，建议每个功能新建一个feature， 具有关联关系的功能公用一个feature分支；
- release：每一次开发完成之后，从develop创建出来的分支，以此分支为基准，进行测试；
- hotfix：该分支主要用于修复线上bug；
命名规范约定如下：
- feature分支命名：feature/name
- release分支命名：release/name
- hotfix分支命名：hotfix/name
比如有一个「优化分布式Session」的需求，可在develop分支的基础上创建新分支 feature/optimize_distributed_session进行开发，开发完成后合并到develop分支。
分支详细介绍和处理流程
master分支
主分支，与线上运行的版本始终保持一致，任何时候都不要直接修改master分支。
一个版本的release分支、hotfix分支开发完成后，会合并代码到master分支，也就是说master分支主要来源于release分支和hotfix分支。
develop分支
开发分支，始终保持最新完成以及bug修复后的代码，新增功能时基于该分支创建feature分支。
一个版本的release分支、hotfix分支开发完成后，也会合并到develop分支，另外，一个版本的feature功能开发完成后，也会合并到develop分支。也就是说develop分支来源于feature、release、hotfix分支。
feature分支
开发新功能或优化现有功能时，会创建feature分支，以develop为基础创建。一般会有多个功能同时开发，但上线时间可能不同，在适当的时候将特定的feature分支合并到develop分支，并创建release分支，进入测试状态。
release分支
当一组feature开发完成，会首先合并到develop分支，开始进入提测阶段时，会创建release分支。
以release分支代码为基准提测，测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。
测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。
hotfix分支
线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支。
特殊情况处理和注意点
develop分支已存在未上线的feature代码, 此时需要紧急上线一个新功能, 但develop的代码不能上，如何处理 ？
- 以master为基线创建feature， 在完成之后，代码合并到master分支；
- 为了保证develop是最新代码，需要从master合并到develop分支；
以develop为基线，创建了f1和f2两个feature分支之后, f1,f2开发一半的时候，发现两个分支代码需要有依赖怎么办 ？
- 最好在开发开始前确定两个功能是否相关,若相关则只创建一个分支,两个功能在一起开发;
- 如果已经创建，则需要合并到一个分支；
一定要保证commit历史记录的整洁，代码合并时，根据情况选择merge或rebase;
使用rebase注意，一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作；
提交说明规范：
- 提交说明最好限制在一行以内，50个字符以下，简明扼要地描述更新内容，空开一行后，再展开详细注解；
上面部分转载自：cloud.tencent.com/developer/a…
软件开发环境
生产环境
面向用户的环境。此环境上的部署的代码经过充分测试，非常稳定，来源于master
开发环境
面向开发者的环境。此环境上部署的代码只经过简单自测，但是能保证正常运行，主要是开发者之间联调使用，来源于develpo。
测试环境
面向测试人员的环境。此环境上部署的代码，由测试人员构建部署，一般情况下来源与release系列的分支，当有hotfix时，也来源于hotfix，它跟踪需要测试的分支，因此来源不固定。
多个release并行的问题
当多个release并行时，发现的bug在多个release上同时存在。
方法一：直接从develop拉出分支，修复bug，然后在这个新分支进行测试，测试通过后，再合并进入多个release分支
方法二：直接在在任意release分支上进行修复，测试通过后，遴选到多个分支。
方法一的来源清晰，更建议使用方法一。
删除时机
这种修复bug的情况，可能会进行多次提交-》打回-》提交-》验证通过的循环。因此他的删除时机，应该是在最终测试通过，合并进入master后，与release分支一同删除。
