Git 提交规范

为什么引入规范？

Git是当前市面上最流行的版本控制工具，良好的提交记录有助于提高代码维护的效率，如果不加以规范约束，这回导致内容随意、质量参差不齐，比如：修复了一个bug、优化了一些功能等，可读性低亦难以维护，所以在项目中引入 commit message 规范已然成为了必要

用什么规范？

现在市面上比较流行的方案是约定式提交规范（Conventional Commits），它受到了 Angular 提交准则的启发，并在很大程度上以其为依据进行优化演进。约定式提交规范是一种基于提交消息的轻量级约定：

它提供了一组用于创建清晰的提交历史的简单规则，使得编写基于规范的自动化工具变得更容易

基本格式如下：

<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的脚注]

格式说明

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

type

type 为必填项，用于制定提交的类型，约定了 feat、fix 两个主要type，以及 docs、style、build、refactor、revert这五个特殊type，当一次改动包括 主要type和特殊type时，统一采用主要type

# 主要type
feat: 增加新功能
fix: 修复bug

# 特殊type
docs: 只改动了文档相关的内容
style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build: 构造工具的或者外部依赖的改动，例如webpack，npm，gradle，maven
refactor: 代码重构时使用
revert: 执行git revert打印的message

# 其他type
test: 添加测试或者修改现有测试
perf: 提高性能的改动
ci: 与CI（持续集成服务）有关的改动
chore: 不修改src或者test的其余修改，例如构建过程或辅助工具的变动

scope

scope 也为必填项，用于描述改动的范围，格式一般为项目功能模块、组件的名字，用来描述本次 commit 影响的范围。

例如： node commits 、go commits。

嵌套层级结构可以用 / 表示，例如 net/http、node-pc/common等
一次提交影响多个模块、组件时可以用 , 隔开，不要自己编造
使用首字母小写的驼峰命名
除具体模块、组件名外，可以使用 base 表示基础结构、框架相关的改动，使用 misc 表示杂项改动，用 all 表示大范围重构

如果一次 commit 含有多个模块，并且这些改动不相互依赖，应尽量拆分成多个 commit，以便更好的追踪和维护

subject

subject 部分是对本次 commit 目的的简短描述，50个字符左右的简要说明，首字母小写，通常是动宾结构，描述做了什么事情，动词用一般现在时，禁止出现 update code 、 fix bug 等无实际意义的描述。

总的规则：

以动词开头，使用第一人称现在时，比如change，而不是changed或changes
尽量使用简单句保证简洁性
第一个字母小写
结尾不加句号（.）
通过翻译检测工具确认英文的正确性和可读性

例如：

select connector by sorting free memory （不需要形如 update about how to select connector … 的啰嗦写法）
fix success tip can not show on IE8 （不需要形如 fix bug of … 的啰嗦写法）

body

body 填写详细描述，主要描述改动之前的情况及修改动机，对于小的修改不作要求，但是重大需求、更新等必须添加body来作说明，可多行

footer只用于以下两种情况

不兼容变动

以BREAKING CHANGE开头，后面是变动的描述、变动的理由以及迁移的方法

什么叫不兼容变动？比如用户密码的加密方式发生改变

关闭issue

当前提交修改了某个 issue

整体的 git message 如下：

feature(数据层): 简短描述

详细描述

BREAKING CHANGE: 不兼容变动

Closes 关闭issue

break changes 指明是否产生了破坏性修改，涉及break changes的改动必须指明该项，类似版本升级、接口参数减少、接口删除、迁移等。

affect issues 指明是否影响了某个问题。例如我们使用 jira 时，我们在 commit message 中可以填写其影响的JIRA_ID，若要开启该功能需要先打通jira与gitlab。

填写方式例如：

re #JIRA_ID
fix #JIRA_ID

落地

方式一

使用 commitizen & cz-conventional-changelog 工具，具体使用自行查阅相关资料

方式二

在 IDEA 编辑器中安装 Git Commit Template 插件，然后在提交代码界面点击相应按钮即可弹出提交模板，具体使用自行查阅资料

Git 常见其他要求

Merge Request要求

代码格式提交前请按项目风格进行格式化。
必须添加测试！ - 提交前必须确认代码可运行。
记得更新文档 - 保证README.md以及其他相关文档及时更新，和代码的变更保持一致性。
创建feature分支 - 最好不要从你的master分支提交 pull request。
一个feature提交一个pull请求 - 如果你的代码变更了多个操作，那就提交多个pull请求吧。
清晰的commit历史 - 保证你的pull请求的每次commit操作都是有意义的。如果你开发中需要执行多次的即时commit操作，那么请把它们放到一起再提交pull请求。详情请了解git rebase

善用 rebase 清理提交日志，具体用法，自行学习

目录CONTENT

Git 开发规范-提交规范