Skip to content
Projects
Groups
Snippets
Help
This project
Loading...
Sign in / Register
Toggle navigation
Conventional-Commits
Overview
Overview
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
1
Issues
1
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Snippets
Snippets
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
郑其龙
Conventional-Commits
Commits
72363859
Commit
72363859
authored
Nov 11, 2019
by
郑其龙
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
docs: 更新README.md,添加图片说明
parent
24d4bf08
Show whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
146 additions
and
0 deletions
+146
-0
README.md
+146
-0
img/git-cz.gif
+0
-0
No files found.
README.md
View file @
72363859
# 导航
本文为介绍约定式提交,主要从以下几点展开:
-
[
约定式提交
](
)
-
[
优点
](
)
-
[
规范
](
)
-
[
commitizen
](
)
-
[
安装使用
](
)
-
[
standard-version
](
)
-
[
安装使用
](
)
# 约定式提交
约定式提交:每次使用
`git commit`
的时候都需要写commit message,如果message style是
`按照固定的模版格式书写`
,对于后期的维护和编写changelog都有巨大的好处。
而且现在的很多自动生成changelog的工具,都是建立在约定式提交的基础之上。
## 优点
-
可读性好,清晰,不必深入看代码即可了解当前commit的作用。
-
为 Code Reviewing做准备
-
方便跟踪工程历史
-
让其他的开发者在运行 git blame 的时候想跪谢
-
提高项目的整体质量,提高个人工程素质
## 约定式提交规范
[
约定式提交规范
](
https://conventionalcommits.org/lang/zh-Hans
)
是基于
[
Angular提交准则
](
https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md
)
形成,提交说明的结构如下:
```
<类型>([可选的作用域]): <描述>
// 空一行
[可选的正文]
// 空一行
[可选的脚注]
```
其中,
`<类型>`
是为了向类库使用者表明其意图,其可选值为:
-
feat: 表示新增了一个功能
-
fix: 表示修复了一个 bug
-
docs: 表示只修改了文档
-
style: 表示修改格式、书写错误、空格等不影响代码逻辑的操作
-
refactor: 表示修改的代码不是新增功能也不是修改 bug,比如代码重构
-
perf: 表示修改了提升性能的代码
-
test: 表示修改了测试代码
-
build: 表示修改了编译配置文件
-
chore: 无 src 或 test 的操作
-
revert: 回滚操作
`[可选的作用域]`
: 是为了描述 此次 commit 影响的范围,比如: route, component, utils, build, api, website, docs
`<描述>`
: 此次提交的简短描述
`[可选的正文]`
: 此次提交的详细描述,描述为什么修改,做了什么样的修改,以及开发的思路等等,输入
`\n`
换行
`[可选的页脚]`
: 主要写下面2种
-
Breaking changes: 在可选的正文或脚注的起始位置带有 BREAKING CHANGE: 的提交,表示引入了破坏性变更(这和语义化版本中的 MAJOR 相对应)。
-
Closed issues: 罗列此次提交修复的 bug,如 fixes issue #110
# Commitizen
[
Commitizen
](
https://github.com/commitizen/cz-cli
)
是一个撰写合格 Commit message 的工具。
## 安装
安装命令如下。
> ```bash
> $ npm install -g commitizen
> ```
然后,在项目目录里,运行下面的命令,使其支持 Angular 的 Commit message 格式。
> ```bash
> $ commitizen init cz-conventional-changelog --save --save-exact
> ```
ps: 对于
`非Node项目`
(java、php...)在执行上一条命令前需要手动创建
[
package.json
](
)文件
```
json
{
"name"
:
"demo"
,
"version"
:
"0.0.0"
,
"private"
:
true
,
"scripts"
:
{
"start"
:
"node ./bin/www"
}
}
```
以后,凡是用到
`git commit`
命令,一律改为使用
`git cz`
。这时,就会出现选项,用来生成符合格式的 Commit message。如图:

## standard-version
如果你的所有 Commit 都符合 Angular 格式,那么发布新版本时, Change log 就可以用脚本自动生成
[
standard-version
](
https://github.com/conventional-changelog/standard-version
)
就是生成 Change log 的工具
## 安装使用
全局安装命令如下:
> ```bash
> $ npm i -g standard-version
> ```
生成CHANGELOG:
> ```bash
> $ standard-version
> ```
# 总结
目前我们的项目在commit时基本上五花八门,各领风骚。这一现象严重影响我们在阅读提交记录和查找bug原因时的效率。
我们可以感受下:

可对比看看同样后端项目
[
Nacos
]
的部分提交记录

其实已经越来越多的人开始意识到规范化提交的重要性,比如就在我们身边,QIQ的前端项目
`Sky`
提交记录

> 为了提高开发效率,减少在处理问题时耗费的时间,推荐大家在写完代码,提交时能够使用以下规范:
-
规范化提交(不一定是文中提到的方式,但无论哪种方式,要做到
`统一`
、
`简明`
)
-
一处变更一次commit(谨防多处、多次修改堆积成一次commit提交,这对后期bug分析将是灾难)
\ No newline at end of file
img/git-cz.gif
0 → 100644
View file @
72363859
124 KB
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment