git commit 规范

转载自 https://zhuanlan.zhihu.com/p/182553920
mark 一下，方便查看

目的

git commit 规范的主要目的是为了规范化 commit 格式，使每次的 commit 清晰指明本次提交的目的、备注信息以及影响范围。

commit message格式

<type>(<scope>): <subject>

type(必须)

用于说明git commit的类别，只允许使用下面的标识。

feat：新功能（feature）。

fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。

fix：产生diff并自动修复此问题。适合于一次提交直接修复问题
to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix
docs：文档（documentation）。

style：格式（不影响代码运行的变动）。

refactor：重构（即不是新增功能，也不是修改bug的代码变动）。

perf：优化相关，比如提升性能、体验。

test：增加测试。

chore：构建过程或辅助工具的变动。

revert：回滚到上一个版本。

merge：代码合并。

sync：同步主线或分支的Bug。

scope(可选)

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

例如在Angular，可以是location，browser，compile，compile，rootScope， ngHref，ngClick，ngView等。如果你的修改影响了不止一个scope，你可以使用*代替。

subject(必须)

subject是commit目的的简短描述，不超过50个字符。

建议使用中文（感觉中国人用中文描述问题能更清楚一些）。

结尾不加句号或其他标点符号。
根据以上规范git commit message将是如下的格式：
fix(DAO):用户查询缺少username属性
feat(Controller):用户查询接口开发
以上就是我们梳理的git commit规范，那么我们这样规范git commit到底有哪些好处呢？

便于程序员对提交历史进行追溯，了解发生了什么情况。
一旦约束了commit message，意味着我们将慎重的进行每一次提交，不能再一股脑的把各种各样的改动都放在一个git commit里面，这样一来整个代码改动的历史也将更加清晰。
格式化的commit message才可以用于自动化输出Change log。

git hooks

Commitizen

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

[1] git commit 规范指南
[2] Git 分支命名规范(完)
[3] Git 分支命名规范