中国电信黄页网青岛百度整站优化服务
目的
俗话说：没有规矩，不成方圆。遵循一个好的规章制度能让你的工作事半功倍。同时也可以展现出你做事的认真的态度以及你的专业性，不会显得杂乱无章，管理困难。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 号，建议在描述中加上。