本规范可以作为公司或团队的规范文档，欢迎大家提供意见来一起补充完善与转发。
1. 规范背景与目的
团队开发中，遵循一个合理、清晰的Git使用流程，是非常重要的，否则每个人都提交一堆杂乱无章的commit，项目很快就会变得难以协调和维护。规范的commit注释也能马上看到这行代码是哪个需求提交的。以下所有规范会按照【强制】、【建议】两个级别进行标注，遵守优先级从高到低。
2. 规范说明
2.1 分支
- 【强制】每次开发新功能，都必须从最新的master分支(或其他依赖分支)上新建一个单独的分支，产品与技术需求以“需求编号”命名，比如：feature-1201，bug修复可以fix/[user]-[yyyyMMdd]命名，user可以是开发人员名称简写。
- 【强制】在需求分支提merge request前，必须先pull master代码，防止代码冲突。
- 【强制】在pull其他分支代码时，对不确定的冲突代码必须先与其开发人员确认，防止合并代码时丢失而导致线上问题。
- 【建议】管理员对分支的merge request代码进行Review。
2.2 注释
- 【强制】git commit必须包含注释。
- 【建议】可以参考业界通用的git提交规范 commitizen，制定适合自己的提交规范。比如可以参考如下的格式规范。
注释格式：type(scope) : subject(分支号) 。其中
type（必须）: commit 的类别，只允许使用下面几个标识：
feat : 新功能
fix : 修复bug
docs : 文档改变
refactor : 某个已有功能重构
perf : 性能优化
test : 增加测试
revert : 撤销上一次的 commit
scope（可选） : 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目的不同而不同。
subject（必须） : commit 的简短描述，不超过50个字符，内容不要是'fix'、'update'、'commit'等这些无用的描述。
分支号（必须）：此次提交的分支号(如feature-878、fix/mary-20200315)，用来查看代码是哪个需求修改，方便后期维护。
如下图一个Git注释提交记录示例：
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
