Git 约定式提交规范实践

标签: tuicool | 发表时间:2019-10-28 00:00 | 作者:
出处:http://itindex.net/relian

约定式提交规范提供了一个轻量级的提交历史编写规则,它的内容十分简单:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

举个简单的例子:

feat(config): 允许 config 对象直接从其他 config 继承

BREAKING CHANGE: 在 config 对象中增加 `extends` 字段,用于从其他继承 config

close issue #23

在 git commit 时,如果你想进行多行 commit 编辑,可以通过 git commit -a进入编辑界面;如果是单行,可以直接 git commit -a -m 'COMMIT MESSAGE'完成提交。

更多的约定

约定式规范与 SemVer的设计是相吻合的,

PATCH -> type(fix)
MINOR -> type(feat)
MAJOR -> BREAKING CHNAGE

大部分的提交中,我们都会使用 fix 和 feat 来描述本次修改的类型,当然也包含其他类型,如 chore/docs/reflector/improvement/perf/test/style,值得注意的是:

  • 一般不用写 body部分的内容,除非存在 BREAKING CHANGE
  • description的内容要相当简明扼要,用简单的语句把修改点直接说出来
  • 一般不建议将多次修改放在一次提交中,尤其是一次半(第二个修改只完成了一部分)的情况
  • scope可以是一个文件的地址,如 /lib/utils;也可以是某个功能点 parser,不建议超过两个单词

一些技巧

合并多次提交

如果你上次修改的内容存在 bug 或未完成,本次提交的内容与上次几乎一样,建议使用 git rebase -i进行提交的合并,如

git rebase -i HEAD~3 # 展示最近 3 次修改

输出如下:

pick 0291959 chore(blog): 清理无关项
pick 1ef8f31 chore(blog): 清理无关项
pick 36a91db fix(post): 格式化 post 的 meta 数据格式,增加 --- 开始符

可以将第二行的 pick修改为 squash,表示保留 commit 但将本次修改合并到上次,相关的操作可以看这篇文章。

关闭 ISSUE

在 github/gitlab 中,如果 commit message 中带有 Fix #23诸如此类的信息,当 commit 被 push 到 repo 后,会自动关闭编号为 23 的 issue。

自动生成 CHANGELOG

在写日报或者周报,或者在项目发版时,我们可以很轻松地从提交日志中看到自己或者团队干了些什么事情:

alias git-changelog='git log --oneline --decorate';

当然也可以使用开源的工程自动生成结构化更强的 CHANGELOG 日志,如 auto-changelog,它提供了可自定义的 CHANGELOG 模板。

项目配置

约定如果没有工具来辅助和约束,大概率就成了一纸空文,毫无意义。在项目实战中,我们可以做如下配置让项目成员强制进行约定式提交。

1. 安装工具

推荐使用 @commitlint/cli进行检测,安装方式:

npm install @commitlint/cli --save-dev

2. 配置约定

@commitlint工具包中有一个规则比较强的检测规范: @commitlint/config-conventional,也安装到项目中:

npm install @commitlint/config-conventional --save-dev

安装完成后,需要显式地配置,在项目中增加 commitlint.config.js

module.exports = { 
  extends: [
    '@commitlint/config-conventional'
  ] 
};

config-conventional中允许类型有 build/chore/ci/docs/feat/fix/perf/refactor/revert/style/test

3. 提交时执行检查

推荐使用 husky这个工具,它会帮助我们自动配置 commit hooks,只需在项目中添加 .huskyrc.json文件:

{
  "hooks": {
    "pre-commit": "node ./node_modules/@commitlint/cli/lib/cli.js -E HUSKY_GIT_PARAMS"
  }
}

当然也可以直接在 package.json 中配置 husky字段,具体可以查看 文档

小结

整洁的提交记录并不仅仅意味着开发者自动生成 CHANGELOG,遵守约定可以给项目沉淀一个结构化的提交历史,再加上一些 emoji,生成出来的文档简直就是一篇生动的项目发展史,它有助于我们向公众传达变化的性质,同时对继续集成也会带来一定的好处,比如我们可以根据 type 触发不同的构建和部署流程。

相关 [git 约定 规范] 推荐:

Git 约定式提交规范实践

- - IT瘾-tuicool
约定式提交规范提供了一个轻量级的提交历史编写规则,它的内容十分简单:. feat(config): 允许 config 对象直接从其他 config 继承 BREAKING CHANGE: 在 config 对象中增加 `extends` 字段,用于从其他继承 config close issue #23.

Git 分支设计规范

- - 掘金后端
这篇文章分享 Git 分支设计规范,目的是提供给研发人员做参考. 规范是死的,人是活的,希望自己定的规范,不要被打脸. 在说 Git 分支规范之前,先说下在系统开发过程中常用的环境. DEV 环境:用于开发者调试使用. FAT 环境:功能验收测试环境,用于测试环境下的软件测试者测试使用. UAT 环境:用户验收测试环境,用于生产环境下的软件测试者测试使用.

Git基础

- Wolf - 潘魏增
上个月末在公司内部作了一次《Git基础》的主题分享. 这里把分享内容公布出来,希望对一些朋友有用. 如果之前没有接触过Git,wikipedia上面已经有非常好的介绍. pdf格式:http://panweizeng.com/download/git-basics-meituan.pdf. keynote格式:http://panweizeng.com/download/git-basics-meituan.key.

Git-rebase 小筆記

- lepture - YORKXIN×YORKXIN
最近剛好有個機會整理很亂的 Git commit tree,終於搞懂了 rebase 的用法,筆記一下. 大家都知道 Git 有個特色就是 branch 開很大開不用錢,但很多 branches 各自開發,總要在適當時機 merge 進去 master. 看過很多 git 操作指南都告訴我們,可以妥善利用 rebase 來整理看似很亂或是中途可能不小心手滑 commit 錯的 commits ,甚至可以讓 merge 產生的線看起來比較簡單,不會有跨好幾十個 commits 的線.

Git 简明教程

- satoru - python.cn(jobs, news)
Git 是一款强大的分布式版本控制系统.在他的官网可以找到已经有很多著名的项目正在使用. Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another.

git架构图解

- - CSDN博客研发管理推荐文章
  最近又遇到Git了,发现网络上Git的资料确实不咋滴,难懂不全面. 至于Git是什么我就不多说了,相比svn上手确实更难. 与svn集中版本库相比较,Git被称作分布式版本库,在分布式的版本库中任何一个库都可以作为中心库看待. 如果说svn是颗树,那么Git就像一张网. Svn在每个目录都有一个.svn文件夹存放信息,而git只在根目录才有,这就决定了svn可以单独拉取某个子目录或者某个文件,而git需要全部拉取.

科普:Git Commit Guidelines

- - IT瘾-dev
降低Review成本,可以明确知道本次提交的改变和影响. 规范整个Team的提交习惯,对技术素养的养成有益. 可以通过统一工具,抽取规范的message自动形成change log. 目前Github的Angular项目,就是完全采用规范的Git Message来进行日常的提交管理和发布管理的,下面是这个项目的Commit记录,和自动根据commit生成的change log.

一些 Git 設定偏好

- dylan - ihower { blogging }
讓 command line 指令列顯示目前處在哪一個 Git Brnach,最早是在 RGBA 看到這一招,非常方便. 請修改家目錄的 ~/.bashrc 或 ~/.bash_profile 檔案:. 記得打開 Git 的 color 設定,這樣 Git 指令的輸出結果才會加上顏色,像是 git status 等:.

Git和Mercurial(Hg)的分析

- gOODiDEA - 译言-电脑/网络/数码科技
来源Analysis of Git and Mercurial. 原文地址:http://code.google.com/p/support/wiki/DVCSAnalysis. (译者注:Mercurial以下简称Hg). 注:这篇分析完成于2008年夏季,当时我们正第一次为Google Code支持DVCS而作的研究工作.

GoogleCode 的 git 使用小记

- Fstone - Gracecode.com
早先就知道 GoogleCode 支持 git,不过一直没时间体验. 近期实在受不了频繁的 svn commit 加上公司的联通网络访问 GoogleCode 实在是慢得让人无法忍受,于是咬咬牙想把 GoogleCode 中那陈年的代码迁移到 git 控制中. 总得来讲,设置 GoogleCode 项目中新的版本控制方案并不复杂,只需要在管理中点击需要的版本控制系统就行.