前言
目前很多项目在开发的过程中都会用到版本控制,而主流的版本控制工具就是 git
和 svn
。
以使用最多的 git
来说,在正常使用的过程中,无非就是拉取、暂存、提交、推送。
这里重点说一下 提交commit
,一般来说,平时大家的提交方式基本是这样的
git commit -m "增加···修改···" |
看上去这样没啥毛病,简单直接粗暴省事。
但是,当我们的项目变得越来越大,提交的次数越来越多后,一旦出现了啥问题,需要去查找提交记录的时候,你会发现非常的不好找。
假如我们期望切换到以前的某一次提交,你会发现 git log
这很难找,因此我们最好是遵循某种规范来进行代码的commit,除了能生成清晰的日志变更记录之外,也更加利于团队之间共同协作。
规范格式
我们可以参考下 Angular
的提交规范:
<description> : |
字段描述:
字段 | 是否必选 | 描述 |
---|---|---|
type | 是 | 本次提交的类型 |
scope | 否 | 受影响的范围,方便定位文件,可以是模块名称,也可以是层次模型名称,或项目名 |
description | 是 | 简短的描述提交内容,不宜过多,就好比文章的标题一样 |
body | 否 | 详细描述本次提交所涉及的内容,以条目形式进行书写,若description可描述清楚,则可不写body |
footer | 否 | 与本次相关联的 breaking change 或 issue |
type附属字段:
字段 | 定义 | 解释 |
---|---|---|
feat | 新功能 | 加入了新的功能或需求,以及对现有功能或需求的变更 |
fix | 修复 | 如修复bug |
doc | 文档 | 描述文档的变更 |
style | 风格 | 与代码风格相关的提交,如格式化代码文件 |
refactor | 重构 | 对已有功能或需求进行重构 |
test | 测试 | 与测试相关的提交,如增加测试用例或配置测试环境等 |
chore | 构建 | 与工程化或构建工具、流程、方法等方面的变更 |
footer附属字段:
字段 | 是否必选 | 描述 |
---|---|---|
breaking change | 否 | 若本次提交产生了破坏性的修改,如大更新、项目迁移、技术栈变更等等,则必须写明 breaking change |
issue | 否 | 若发现项目出现bug,或想为项目提出某些需求或建议,则可在 issue 中指明 |
示例
我们可以来看看几个提交例子:
新需求的变动:
完成XXX界面第一阶段开发 : |
界面重做的变动:
完成首页改造 : |
修复bug的变动:
修复登录界面的一系列问题 : |
代码风格上的变动:
统一所有文件的代码书写风格 : |
测试相关的变动:
新增注册界面单元测试 : |
工程上的变动:
工程化配置变更 : |
其他
若提交的信息比较多,需要写多行,那么建议是让git自动打开对应的文本编辑器来进行书写
步骤如下:
- 输入以下命令,然后直接回车
git commit |
- 根据你安装git时选择的默认文本编辑器的不同,进行提交信息的书写
- 填写好自己的提交内容后,关闭文件或退出编辑模式即可
退出编辑模式的方式:
- 如果是
vim
:先按下ESC
,再输入:wq
- 如果是
GUN nano
:先按下ctrl + o
,然后按下回车
保存,最后按下ctrl + x
退出 - 如果是
vscode
:直接关闭正在编辑的选项卡