分支管理规范主要遵循gitflow的分支管理流程，见下图：
- Workspace：工作区，平时我们写代码的地方。
- Index：暂存区，写完代码后让它变成的待提交的状态。
- Repository：本地仓库，提交暂存区的代码到这里，记录进入代码本地管理。
- Remote：远程仓库，将本地仓库的修改的代码提交到远程，可以供远程协作的人下载。
开发规范
长期的使用的分支有两个master分支和dev分支，hotfix分支、feature分支以及release分支都是临时分支，其生命周期在合并到dev或master上之后就基本结束，在分支生命周期结束之后尽快删除掉，以免堆积太多的分支而导致混乱；
开发过程中要勤提交、勤合并，原则上一些方法级别、类级别或单元测试级别的修改可以发起一次提交，提交的信息写明工作的内容，一个feature或bug的自测完成可以发起一次合并请求，合并请求的提交内容要写清楚具体的开发工作内容描述，切勿堆积很大的工作量才发起合并
master分支
只存线上的代码，只有确定可以上线时的才合并到master上，并且在master的基础上打Tag。
dev分支
初次创建dev时，需要从master分支拉取，保持开发时代码和线上最新的代码相同。dev分支是在开发时的最终分支，具有所有当前版本需要上线的所有功能。
feature分支
用于开发功能的分支，必须从最新的dev分支代码拉取。分支命名基本上是feature/功能相关名字的拼音。
不强制提交到远程仓库，可以本地创建。
举例:我要开发注册功能，我从dev分支的最新代码创建新分支命名为feature/zhuce，然后切换到这个新分支开始开发。开发并测试完成后，合并到dev分支。
release分支
当dev分支已经有了本次上线的所有代码的时候，并且以通过全部测试的时候，可以从dev分支创建release分支了，release分支是为发布新的产品版本而设计的。
通过在release分支上进行这些工作可以让dev分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。
比如，此次1.0版本所有的功能版本都已经合并到了dev上，并且所有测试都已经通过了测试，那我就创建新的release分支release/v1.0。切换到新分支，修改最新的版本号等，不允许大的更改。
hotfix分支
只有当线上出现bug需要紧急修复时，从当前master分支拉去出hotfix分支。修改线上bug，修改完成后合并回dev和master分支。比如，在线上v1.0注册功能出现问题，我从master拉取代码创建新的分支hotfix/v1.0_zhuce，修改完成后合并到master和dev上
正常的业务开发流程：
当接收到正常的业务需求时，需要约定一个大的发布版本（一次迭代）以及这个发布版本包含的多个功能，一个发布版本必须在一个时间点上发布（工作量在1或2日为准，最好控制在一天以内）。
以dev为基准创建一个分支，分支名称为“feature-功能名称拼音简写-开发人员花名全拼”，如“feature-zhuce-mutao”，注册功能的所有开发工作都在feature-zhuce-mutao分支上进行，所有开发过程的commit message需要填写具体的开发内容。
开发及单元测试工作完成后创建请求合并到dev分支，合并请求消息同样需要功能的内容描述以及具体的开发内容。
开发人员的自测工作基于合并后的dev分支代码进行，如果这个发布版本所有功能全部自测通过后,提交到测试人员进行测试。
测试人员dev分支上进行回归测试和验证，如果存在bug直接在该分支修改并合并到dev分支；如果验证通过则准备生产上线，
生产上线时将dev代码合并到master分支，并打tag，tag名称为“tag-版本号”，从master打包上线。
线上紧急bug修复流程：
当发现线上bug需要紧急修复时（开发人员需要确保bug修复已经在jira录入），需要以master分支为基准创建一个hotfix分支，分支名称为“hotfix-jira编号-开发人员姓名全拼”；bug修复代码直接在新建的hotfix分支上提交，commit message需要填写具体的开发内容。测试人员直接在hotfix分支测试测试通过后，开发人员同时请求合并到master分支和dev分支，合并请求消息同样需要复制jira的任务描述以及具体的开发内容。生产上线时将hotfix代码合并到master分支，并打tag，tag名称为“tag-版本号-jira编号”，从master打包上线。
高优先级开发任务流程：
如果在其他发布版本或迭代在开发中，而优先级更高的迭代需要同时进行，则需要特别注意。在创建feature分支时，要确保dev分支和master分支时一致的没有被未上线甚至未测试的代码污染过的，如果是则直接以dev分支为基准创建新的分支，命名规范如同正常的业务需求流程；如果dev分支上已经有其他未上线分支的代码且该分支代码上线优先级较低，则不能以dev分支为基准创建分支，需要以master分支为基准创建分支。当更高优先级feature功能开发和自测完成后，需要上测试环境，这时，需要以master分支为基准创建一个release分支，release分支名称为“release-版本号”，所有较高优先级的feature分支合并到高优先级的release分支上，并在该分支进行测试。release分支测试通过后，合并到master分支准备上生产，同时release合并到dev分支；master分支生产上线后打tag，tag名称为“tag-版本号”。
上次更新时间 13 3 月, 2023 at 09:59 上午