提交规范 | IT科技圈

前言

目前很多项目在开发的过程中都会用到版本控制，而主流的版本控制工具就是 git 和 svn 。

以使用最多的 git 来说，在正常使用的过程中，无非就是拉取、暂存、提交、推送。

这里重点说一下 提交commit ，一般来说，平时大家的提交方式基本是这样的

git commit -m "增加···修改···"

看上去这样没啥毛病，简单直接粗暴省事。

但是，当我们的项目变得越来越大，提交的次数越来越多后，一旦出现了啥问题，需要去查找提交记录的时候，你会发现非常的不好找。

假如我们期望切换到以前的某一次提交，你会发现 git log 这很难找，因此我们最好是遵循某种规范来进行代码的commit，除了能生成清晰的日志变更记录之外，也更加利于团队之间共同协作。

我们可以参考下 Angular 的提交规范：

<type>[scope]: <description>
[body]
[body]
[body]
···
[footer]

字段描述：

字段	是否必选	描述
type	是	本次提交的类型
scope	否	受影响的范围，方便定位文件，可以是模块名称，也可以是层次模型名称，或项目名
description	是	简短的描述提交内容，不宜过多，就好比文章的标题一样
body	否	详细描述本次提交所涉及的内容，以条目形式进行书写，若description可描述清楚，则可不写body
footer	否	与本次相关联的 breaking change 或 issue

type附属字段：

footer附属字段：

字段	是否必选	描述
breaking change	否	若本次提交产生了破坏性的修改，如大更新、项目迁移、技术栈变更等等，则必须写明 breaking change
issue	否	若发现项目出现bug，或想为项目提出某些需求或建议，则可在 issue 中指明

我们可以来看看几个提交例子：

新需求的变动：

feat(StockCheck): 完成XXX界面第一阶段开发
    - 新增XXX详情页
    - 新增XXX功能
    - 删除XXX功能
    - 修改XXXXX

界面重做的变动：

refactor(Index): 完成首页改造
breaking change: 新版首页将完全替代旧版首页，旧版首页将被抛弃

修复bug的变动：

fix(Login): 修复登录界面的一系列问题
	- 点击重置按钮没反应
	- 可以提交空信息
	- 大图片无法上传

代码风格上的变动：

style(pages): 统一所有文件的代码书写风格
	- 缩进一律使用tab
	- 统一采用单引号
	- ····

测试相关的变动：

test(Register): 新增注册界面单元测试
	- 增加判空测试
	- 变更范围测试用例
	- ···

工程上的变动：

chore(project): 工程化配置变更
	- 采用webpack取代gulp
	- 新增Sass预处理
	- 增加TS解析器
	- 增加Gzip压缩配置
	- 增加代码分割配置
	- ···

若提交的信息比较多，需要写多行，那么建议是让git自动打开对应的文本编辑器来进行书写

步骤如下：

git commit

退出编辑模式的方式：