目的

俗话说：没有规矩，不成方圆。遵循一个好的规章制度能让你的工作事半功倍。同时也可以展现出你做事的认真的态度以及你的专业性，不会显得杂乱无章，管理困难。Git分支规范也是一样。当遵循了某种约定的Git分支，在代码提交以及多开发、多分支协同工作的时候，必须遵循这个规范操作，否则不予以提交、合并代码、提测、上线等操作。

适用范围

适用Git管理开发的所有项目

---

分支约定

Git Flow有主分支和辅助分支两类分支，通常主分支也被称为长期分支。

• 主分支用于组织与软件开发、部署相关的活动；

• 辅助分支组织为了解决特定的问题而进行的各种活动。

主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。

分支介绍

•    tag：

使用release发布生产成功后，三日之内把release分支合并到master上并打tag。

使用realase分支创建tag版本，使用tag进行线上部署

生产流水线自动打tag

•    master分支：

不接受commit，只接受来自realase分支的merge操作

分支必须开启分支保护，只有维护者可以操作

•    release分支：

可从test/master分支上拉取；

不接受commit，只接受来自对应test分支的合并操作；

普通开发人员不具有合并权限，需要管理员才能合并

release分支用于发布预生产环境部署；

上线成功后必须立即合并到master

release分支用于发布生产环境部署，上线完成后，禁止合并；

•    test分支

从master/develop分支拉取，用于测试环境部署

不接受commit提交，只接受来自对应develop的合并

•    develop分支：

从master/feature分支拉取，用于开发环境部署

不接受commit提交，只接受来自feature的合并

•    feature分支：

不限制从什么分支拉取，拉取代码时候版本号必须大于等于最新master的版本

可直接commit

一般不用于任何环境部署，特殊情况可以用于开发环境部署

禁止用于测试、预生产、灰度、生产部署

bug修复分支，也按feature分支规范和流程

•    hotfix分支

紧急bug修复分支，仅用于紧急的线上问题修复，普通bug修复还是使用feature分支规范

分支命名规则及对应环境

分支	命名规则	名称	环境	权限
master	master	主分支，保护分支，只接受merge	-	保护
tag	tag-{上线时间}-v{版本号}	tag 如：tag-20220803-v1.2.0	-	只读
release	release-{时间}-{版本号}-{创建人} ；	预上线分支；release-20220803-v1.2.0-liuyy	预生产、生产	保护
test	test-{时间}-{功能描述}-{创建人} ；除了前缀，名称与develop一致	测试部署分支； test-20220803-superChargeV1-liuyy	测试	保护
develop	develop-{时间}-{功能描述}-{创建人}  ； 除了前缀，名称与feature一致	开发部署分支；develop-20220803-superChargeV1-liuyy	开发	常规
feature	feature-{创建时间}-{功能描述}-{创建人}	功能开发分支；feature-20220803-superChargeV1-liuyy	-	常规
hotfix	hotfix-{创建时间}-{bug描述}-{创建人}	紧急bug修复分支；hotfix-20220803-bugxxx-liuyy	不限	常规

分支规则正则：

--javascripttypescriptbashsqljsonhtmlcssccppjavarubypythongorustmarkdown

^(test|feature|develop|hotfix)-(20\d{6})(-\w+){2}$|^(release|tag)-(20\d{6})-v\d+(\.\d+){2}(-\w+){0,1}$

分支使用示意图

总结

1、一个上线需求一个feature分支，正常情况feature、develop、test、release分支是一一对应的

2、如果有多个需求需要合并上线，那么需要从develop分支开始合并，即多个feature对一个develop分支，但develop、test、release也还是一一对应的

3、除了feature分支外，所有分支都不接受commit，只接受合并

4、普通bug修复使用feature分支，流程一样

5、紧急bug修复走hotfix分支流程

6、所有上线的代码必须走完完整的develop、test、release流程

代码提交规范

• 所有commit必须有注释，内容必须简洁明了的描述本次commit涵盖了哪些内容。严禁注释内容过于简单或不能明确表达提交内容的！

• 合理控制提交内容的颗粒度，一次commit含一个独立功能点。严禁一次提交涵盖多个功能项。

• 提交注释字符数务必大于8, 尽量控制在60个字符之内。

建议参考规范：

示例：

fix(首页模块)：修复弹窗 JS Bug。

type(可选）表示动作类型，可分为：

• fix：修复 xxx Bug

• feat：新增 xxx 功能

• test：调试 xxx 功能

• style：变更 xxx 代码格式或注释

• docs：变更 xxx 文档

• refactor：重构 xxx 功能或方法

scope(可选） 表示影响范围，可分为：模块、类库、方法等。

subject(必须) 表示简短描述，大于8个字符，小于 60 个字，如果有编号的 Jira 号，建议在描述中加上。