Gitlab学习之企业常用的一些git规范
俗话说，没有规矩不成方圆，我们的git也需要规范。
下面介绍一下企业常用的一些规范。
分支管理规范
分支命名不能千奇百怪，必须有统一的命名方式。主要有以下几种：
| 分支管理 | 命名规范 | 解释 |
|---|---|---|
| master 主分支 | master | 稳定版本分支，上线完成回归后后，由项目技术负责人从 release 分支合并进来，并打 tag |
| test 测试分支 | test/yyyyMMdd_ 功能名称示例：test/20220426_blog | 测试人员使用分支，测试时从 feature 分支合并进来 |
| feature 功能开发分支 | feature/yyyyMMdd_ 功能名称_负责人员示例：feature/20220426_blog_xiumubai | 新功能开发使用分支，基于master建立 |
| fix bug修复分支 | fix/yyyyMMdd_ 功能名称_负责人员示例：fix/20220426_blog_xiumubai | 紧急线上bug修复使用分支，基于master建立 |
| release 上线分支 | release/版本号示例：release/0.1.0 | 用于上线的分支，基于 master 建立，必须对要并入的 feature 分支进行 Code review 后，才可并入上线 |
版本号管理规范
当我们上线的时候，需要给版本号打tag，下面是版本号规范：
项目上线release分支创建定义： 第一个数字是主版本。第二个数字是次版本。第三个数字是补丁版本(hotfix 类的更新)。 主版本：含有破坏性更新、大调整等。 例如：1.1.0 > 2.0.0 次版本：增加新功能特性。例如：1.1.0 > 1.2.0 补丁版本：修复问题等。例如：1.1.0 > 1.1.1登录后复制
提交信息规范
最后是commit的时候，需要对commit信息规范，必须要加前缀
| 前缀 | 解释 |
|---|---|
| feat | 新功能 |
| fix | 修复 |
| docs | 文档变更 |
| style | 代码格式 |
| refactor | 重构 |
| perf | 性能优化 |
| test | 增加测试 |
| revert | 回退 |
| build | 打包 |
| chore | 构建过程或辅助工具的变动 |
下图是vue3源码的提交信息规范：
下面我们就实际操作一下，如果通过husky+commitlint集成一个统一规范的git commit信息。
配置 git 提交的校验钩子
- husky: git提交时触发hooks
- commitlint: 对提交的内容做规范校验 husky，主要对pre-commit和commit-msg钩子做校验。
# 安装husky yarn add husky -D 1. 初始化husky配置，在根目录新增.husky配置文件。初始化配置pre-commit npx husky-init 1. 另外新增一个hooks，commit-msg npx husky add .husky/commit-msg登录后复制
在commit-msg文件中添加 npm run commitlint
在pre-commit文件中有个npm run test我们先注释掉，不然会报错。
安装commitlint
# 添加依赖文件 yarn add @commitlint/config-conventional @commitlint/cli -D登录后复制
module.exports = { extends: ['@commitlint/config-conventional'], // 校验规则 rules: { 'type-enum': [ 2, 'always', [ 'feat', 'fix', 'docs', 'style', 'refactor', 'perf', 'test', 'chore', 'revert', 'build', ], ], 'type-case': [0], 'type-empty': [0], 'scope-empty': [0], 'scope-case': [0], 'subject-full-stop': [0, 'never'], 'subject-case': [0, 'never'], 'header-max-length': [0, 'always', 72], }, }登录后复制
