科普:Git Commit Guidelines

标签: dev | 发表时间:2020-12-22 00:00 | 作者:
出处:http://itindex.net/relian

为什么需要


  • 降低Review成本,可以明确知道本次提交的改变和影响
  • 规范整个Team的提交习惯,对技术素养的养成有益
  • 可以通过统一工具,抽取规范的message自动形成change log

GitHub Angular Demo


目前Github的Angular项目,就是完全采用规范的Git Message来进行日常的提交管理和发布管理的,下面是这个项目的Commit记录,和自动根据commit生成的change log

遵循什么规范


目前,使用较多的是AngularJS规范

  # 包括三个部分:Header,Body 和 Footer   
 
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

Header

包括三个字段:type(必需)、scope(可选)和subject(必需)

任何一行都不能超过100个字符

type

用于说明 commit 的类别,类型包含如下几种

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing or correcting existing tests
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
  • revert: Reverts a previous commit
  • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)

如果type为feat和fix,则该 commit 将肯定出现在 Change log 之中。其他情况由你决定,要不要放入 Change log。

scope

用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同

subject

subject是 commit 目的的简短描述

Body

Body 部分是对本次 commit 的详细描述,可以分成多行

Footer

Footer 部分只用于两种情况

不兼容变动

如果当前代码与上一个版本不兼容,则 Footer 部分以BREAKING CHANGE开头,后面是对变动的描述、以及变动理由和迁移方法

关闭问题

如果当前 commit 针对某个issue,那么可以在 Footer 部分关闭这个 issue。

如:Closes #123, #245, #992

工具约束


我们的目标还是要通过工具生成和约束

Commitizen

commitizen/cz-cli 代替git commit

我们需要借助它提供的 git cz 命令替代我们的 git commit 命令, 帮助我们生成符合规范的 commit message

  # 如何安装,在安装之前请先安装npm   
# 全局安装 commitizen
npm install commitizen -g

除此之外, 我们还需要为 commitizen 指定一个 Adapter 比如: cz-conventional-changelog (一个符合 Angular团队规范的 preset). 使得 commitizen 按照我们指定的规范帮助我们生成 commit message

  # 进入到我们项目的根目录   
 
cd your_repo_root_path
# 初始化package.json
npm init --yes
# 为commitizen指定适配器
commitizen init cz-conventional-changelog --save-dev --save-exact

现在我们就可以用git cz去进行提交了

但是问题来了,如果我们此时还用git commit -m "" 去提交,也是允许的,但是这肯定不是我们想要的,因为我们需要对message进行格式限制,所以,我们需要下面的检验插件commitlint + Husky

Commitlint + Husky

commitlint可以帮助我们检查校验提交的message

如果我们提交的不符合指向的规范, 直接拒绝提交

校验 commit message 的最佳方式是结合 git hook, 所以需要配合Husky

  # 在我们的项目根目录   
npm install --save-dev @commitlint/{config-conventional,cli}
npm install husky --save-dev

# 在package.json尾部加入如下结构
"husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    } 
}
 
 
# 在项目根目录新增文件commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
  'type-enum': [2, 'always', [
     "feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert"
   ]],
  'scope-empty': [2, 'never'],
  'subject-full-stop': [0, 'never'],
  'subject-case': [0, 'never']
  }
};

现在,我们可以在试试git commit -m "test"看看是否可以正常提交,应该会得到下面的拦截记录

Standard Version

通过以上工具的帮助, 我们的工程 commit message 应该是符合Angular团队那套,这样也便于我们借助standard-version这样的工具, 自动生成 CHANGELOG, 甚至是语义化的版本号(Semantic Version)

  # 在项目根目录   
npm install --save-dev standard-version
# 在scripts结构体中加入执行脚本
{
  "scripts": {
    "release": "standard-version"
  }
}
# 生成changelog
# 第一次生成
npm run release -- --first-release
# 后续生成
npm run release

会在我们项目根目录生成一个CHANGELOG.md文件,如下所示

项目中如何使用


如果我们已经完成了上述操作,会发现我们最终会得到一个package.json,我们只需要把package.json / commitlint.config.js提交版本库即可

把node_modules 和 package-lock.json都加入git忽略文件

下次再新clone项目后,直接在项目根目录运行npm install即可完成上述所有步骤

PS:NPM有时候国外镜像不稳定,可以切换淘宝镜像

  npm config set registry https://registry.npm.taobao.org   

相关 [科普 git commit] 推荐:

科普:Git Commit Guidelines

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

如何找回git 中丢失的提交(commit)

- ※ABeen※ - liuhui998
如何找回git 中丢失的提交(commit). 在玩git的过程中,常有失误的时候,有时把需要的东东给删了. 不过没有关系,git给了我们一层安全网,让们能有机会把失去的东东给找回来. 我们先创建一个用以实验的仓库,在里面创建了若干个提交和分支. BTW:你可以直接把下面的命令复制到shell里执行.

COMMIT和数据一致性

- - Oracle - 数据库 - ITeye博客
[align=justify; direction: ltr; unicode-bidi: embed; vertical-align: baseline;]2.在执行一条update语句后一直未提交,数据会写到数据文件中吗. 一致性查询及一致性读原理. 如果8点钟可以查询出两条记录,假设一下,如果此查询很慢,从8点开.

Git基础

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

量化InnoDB group commit的效果

- - OurMySQL
前几天有位开发的同学问了个问题,InnoDB的group commit效果如何. 之前说好了回头给看下,结果险些拖过年. Group commit 背景.         InnoDB的redo log的group commit历史比较悠久了(有别于binlog的group commit). 如果设置为1,每次事务提交都至少需要写一次redolog.

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需要全部拉取.

[转]从SQL语言的分类谈COMMIT和ROLLBACK的用法

- - 小彰
从功能上划分,SQL语言可以分为DDL,DML和DCL三大类.     数据定义语言,用于定义和管理 SQL 数据库中的所有对象的语言 ;.     CREATE---创建表.     ALTER---修改表.     DROP---删除表.     数据操纵语言,SQL中处理数据等操作统称为数据操纵语言 ; .

MySQL5.6.12 Waiting for commit lock导致从库hang住的问题剖析

- - CSDN博客推荐文章
nagios报警,线上一台从库检测不到slave状态,于是远程上去查看问题:. 1,show slave status\G卡住:. show slave status卡住了,动弹不了,这种情况还是第一次遇到. 3,Top看mysqld进程占据cpu才0.3%. 4,查看error日志,没有发现异常记录:.