Git分支管理与语义化提交
# 一、分支管理
# 1.1 环境分支
# 1.1.1 开发分支（dev）
我们在此分支的基础上进行迭代
# 1.1.2 测试分支（sit）
我们将功能分支已经进行完冒烟测试，预提交SIT测试的代码合并到dev分支，再从dev分支合并到sit分支，再进行发包部署。
# 1.1.3 用户验收测试分支（uat）
sit分支的代码经测试同事测试通过以后，我们将sit分支合入uat分支进行发包部署
若无客户在发布生产前就行验收测试，这个分支可忽略
# 1.2 功能分支（feature/**）
功能分支的名称为"feature/{功能模块名称}",代码基于dev分支创建。 功能分支提交的代码，必须保证是此功能模块的，禁止将功能A的代码在功能B进行提交。
# 1.3 紧急缺陷修复分支（hotfix）
紧急线上 bug 修复分支，紧急即需要立刻尽快去处理发布上线（自 master 拉取）, 直接进行测试及上线。分支命名：hotfix/{功能}，如 bugfix/SEO
# 1.4 缺陷修复分支（bugfix分支）
非紧急上线的 bug 修复分支, 如非当天上线即使用 bugfix 进行命名（自 master 拉取） , 直接进行测试及上线。分支命名：bugfix/{功能}_年月日，如 bugfix/SEO_20220701
# 1.5 发布分支(release)
作为提测及上线分支，release是发布正式版本之前（即合并到 master 分支之前），需要有一个预发布的版本进行测试。分支命名：release/版本号{功能}年月日，
# 1.6 主干分支（master）
版本迭代完成后的归档的主干分支
# 1.7 里程碑标签
在版本迭代完成成功上线后，基于master分支创建tag，tag的名称为v{版本号}(例如v3.0.1)，在创建tag的备注里需要明确上线的日期，也可以讲迭代的功能写在备注信息里；若无版本号的规划，tag的名称为pro_{上线日期}（例如pro20220528)
# 二、Commitlint 语义化提交规范
在公司产品的迭代开发中，有时会出现同时开发多个产品版本的情况，清晰规范的git提交日志，有助于合并、分离功能版本，我们现在使用commitlint + husky 对git提交日志进行规范。
首先，我们必须保证本次提交的内容是独立的，没有把不同模块，不同功能的代码一起提交，也禁止将未完成的功能提交。
commitlint 推荐我们使用 config-conventional 配置去写 commit
配置文件是commitlint.config.js
- 提交格式 （注意冒号后面有空格）
git commit -m <type>[optional scope]: <description>
- 常用的 | type 类型
| Syntax | Description |
|---|---|
| Header | Title |
| Paragraph | Text |
| 类型 | 描述 |
|---|---|
| build | 编译相关的修改，例如发布版本、对项目构建或者依赖的改动 |
| chore | 其他修改, 比如改变构建流程、或者增加依赖库、工具等 |
| ci | 持续集成修改 |
| docs | 文档修改 |
| feat | 新特性、新功能 |
| fix | 修改bug |
| perf | 优化相关，比如提升性能、体验 |
| refactor | 代码重构 |
| revert | 回滚到上一个版本 |
| style | 代码格式修改, 注意不是 css 修改 |
| test | 测试用例修改 |
-例子
git commit -m 'feat(account): 新增了账户管理的功能'
git commit -m 'refactor: 重构了整个项目'
2
有了这些规范的git log,在交付发版的时候，我们可以使用conventional-changelog一键生成本次版本的change log了