非规范痛点
- 多人合作开发，commit注释，随机编写规范提交格式
- 提交日志太多，无法查找(规范后可以过滤查找)
- 读不懂别人的提交日志 掌握提交语法
好处
git commit规范的主要目的是为了规范化commit格式，使每次commit清晰指明本次提交的目的，备注信息以及影响范围
语法
git commit -m 'type(scope): subject'
commit格式
- type 必填
- scope 可选项，一般用户写入模块
- subject 陈述信息
head详解
| 关键字type | 说明 |
|---|---|
| feat | 新增功能 |
| fix | bug修复 |
| docs | 文档更新,README.md等 |
| style | 不影响程序逻辑的代码修改(修改空白字符，格式缩进，补全缺失的分号等，没有改变代码逻辑) |
| refactor | 重构代码，不是修改不bug，也不是新增功能feart |
| perf | 性能, 体验优化 |
| test | 新增测试用例或是更新已存在测试 |
| build | 修改构建系统，例如（gulp rollup webpack）等配置文件修改 |
| ci | 修改持续集成文件，例如：ravis，Jenkins，GitLab CI，Circl等提交 |
| revert | 回退版本到某个更早提交 |
| chore | 没有上述变动，其他；例如需修改test src目录 打包发布前，提交用chore |
| depc | 升级依赖 |
练习测试
例如：新增功能首页git commit -m 'feat(Home): 新增首页功能'
例如：修改详情页buggit commit -m 'fix(Detail): 修改bug'
例如：打包发布button组件git commit -m 'chore(all): 打包发布button组件'
过滤查找
git log --pretty=oneline --grep=feat
git分支命名规范
| 分支 | 命名 | 说明 |
|---|---|---|
| 主分支 | master | 主分支，所有提供给用户使用的正式版本，都在这个主分支上发布，不能直接在该分支上开发 |
| 开发分支 | dev | 开发分支，永远是功能最新最全的分支，该分支只做只合并操作，不能直接在该分支上开发 |
| 功能分支 | feature-xxx | 功能开发分支，在develop上创建分支，以自己开发功能模块命名，功能测试正常后合并到develop分支 |
| 预发布分支 | release-xxx | 发布定期要上线的功能，它是指发布正式版之前，(即合并到Master分支之前)，我们可以需要有一个与发布版本进行测试。预发布分支是从Dev分支上面分出来的，预发布结束后，必须要合并进Dev和Master分支 |
| 修复分支 | fix-xxx | 功能bug修复分支，feature分支合并之后发现bug，在develop上创建分支修复，之后合并回develop分支 |
| 紧急修复分支 | hotfix-xxx | 紧急bug修复分支，在master分支上创建，修复完成后合并到master |