一直以来,因为团队项目迭代节奏很快,每次发布的更新日志和版本更新都是通过人肉来完成的。有时候实在忙的团团转,对于手动的写这些更新信息就显得力不从心了。对于团队新来的小伙伴,有时候遇到些紧急情况,就更显的乱糟糟,还是得麻烦团队资深的同学。显然这些工作,用自动化工具再适合不过了。

本文是一篇项目自动化方面的使用教程,社区里面针对四类问题的解决方案很多,今天这里主要介绍的是 onventional-changelog 方案相关的内容。 如果你正在思考或者试图解决这方面的问题的话,不妨了解一下。

conventional-changelog

conventional-changelog 是一款可以根据项目的commit 和 metadata信息自动生成 changelogs 和 release notes的系列工具,并且在辅助 standard-version 工具的情况下,可以自动帮你完成生成version、打tag, 生成CHANGELOG等系列过程。

conventional-changelog 生态主要模块

以上是 onventional-changelog 生态重要的几个主要模块,实际工作中这几个工具常常是配套使用的,当然也需要根据自己的情况而定。篇幅有限,今天我们就主要介绍 commitizenconventional-changelog-cli 、standard-version 这三工具了。

commitizen

commitizen 是一款标准化 git commit 信息的工具。在没有规范的情况下,开发人员的 commit 信息是常常是随意的,这就导致 commit 信息显的很无用。可是当你在做git logcode review、编写changelog等情况时,良好的 commit 规范就显的尤为重要。

commitizen 安装
$ npm install -g commitizen
# 或者本地安装
$ npm install --save-dev commitizen
安装适配器(Adapter)

因为不同的项目本身的构建方式的不同,commitizen 支持不同适配器的扩展,从而去满足不同的构建需求的。本文主要使用cz-conventional-changelog的构建标准,当然你也可以根据具体的情况选择其他的适配器,更多请看

$ npm install -g cz-conventional-changelog

全局安装完成后,我们需要在项目根目录下添加 .czrc 配置文件,文件内容如下:

// path 用来指定适配器
{ "path": "cz-conventional-changelog" }
本地安装
$ npm install cz-conventional-changelog --save-dev
# 或者使用 commitizen 工具
$ commitizen init cz-conventional-changelog --save-dev --save-exact

commitizen 工具会自动在package.json中添加配置相应的配置,具体如下:

  "config": {
"commitizen": {
"path": "cz-conventional-changelog"
}
}

安装并添加完后,我们便可以使用 git cz 命令替换 git commit 来使用了。我们修改一个文件并 git add 后,通过 git cz 试一下:

可以看到,git cz 给出了 commit 的几种类型选项,如下:

  • feat 新功能
  • fix Bug 修复
  • docs 文档更新
  • style 代码的格式,标点符号的更新
  • refactor 代码重构
  • perf 性能优化
  • test 测试更新
  • build 构建系统或者包依赖更新
  • ci CI 配置,脚本文件等更新
  • chore 非 src 或者 测试文件的更新
  • revert commit 回退

使用的时候,我们应该根据项目具体变更情况选择。如果想修改已经打好的 commit 信息,我们可以通过 git reset命令来修复。

需要注意的是,仅仅是添加 commit 工具是不够的,为了保证 commit 格式的一致性,这里强烈建议你记得整合 commitlint 工具, 配合 git commit-msg hook 来使用,在这里就不相信介绍了,具体可以查看官方文档。

conventional-changelog-cli

conventional-changelog-cli 默认推荐的 commit 标准是来自angular项目,除了 angular 标准以外,目前集成了包括 atom, codemirror, ember, eslint, express, jquery 等项目的标准,具体可以根据自己口味来选用。

安装
# Help conventional-changelog --help
$ npm install -g conventional-changelog-cli

基本使用

$ conventional-changelog -p angular -i CHANGELOG.md -s

以上命令中参数-p angular用来指定使用的 commit message 标准,假如想使用atom的标准,则是:

$ conventional-changelog -p atom -i CHANGELOG.md -s

参数-i CHANGELOG.md表示从 CHANGELOG.md 读取 changelog, -s 表示读写 changelog 为同一文件。需要注意的是,上面这条命令产生的 changelog 是基于上次 tag 版本之后的变更(Feature、Fix、Breaking Changes等等)所产生的,所以如果你想生成之前所有 commit 信息产生的 changelog 则需要使用这条命令:

$ conventional-changelog -p angular -i CHANGELOG.md -s -r 0

其中 -r 表示生成 changelog 所需要使用的 release 版本数量,默认为1,全部则是0。

自定义参数

生成的 changlog 中有些常用内容可以通过自定义参数来根据需求更改,例如版本号、commit 地址等等。 changelog 中生成的版本号即是从 package.json 中获取 version 字段来的。commit 连接的仓库地址我们需要修改 package.json 中的repository地址,changelog 中 issuse 默认的连接地址也是根据 repository 来生成的。如果你使用了第三方的协作系统(例如 bitbucket), 那么你可以使用这个标准conventional-changelog-angular-bitbucket。或者像我们使用 redmine 来管理 isssue ,那么在生成 changelog 后可以使用 replace 工具来处理文本中的原有地址:

$ replace 'https://github.com/myproject/issues/' 'https://redmine.example.com' CHANGELOG.md

最后看看大致生成的效果:

conventional-changelog 更多的选项配置可以看这里。

standard-version

standard-version 是一款遵循语义化版本( semver)和 commit message 标准规范 的版本和 changlog 自动化工具。通常情况线下,我们会在 master 分支进行如下的版本发布操作:

1. git pull origin master
2. 根据 pacakage.json 中的 version 更新版本号,更新 changelog
3. git add -A, 然后 git commit
4. git tag 打版本操作
5. push 版本 tag 和 master 分支到仓库

其中2,3,4则是 standard-version 工具会自动完成的工作,配合本地的 shell 脚本,则可以自动完成一系列版本发布的工作了。

安装 & 使用

在这里我仍然推荐的全局安装:

$ npm install -g standard-version
# 或者
$ npm install --save-dev standard-version

执行:

# Help standard-version --help
$ standard-version

执行 standard-version 命令,我们会在控制台看到整个执行流程的 log 信息,在这里几个常用的参数需要注意下:

--release-as, -r 指定版本号

默认情况下,工具会自动根据 主版本(major),次版本( minor) or 修订版(patch) 规则生成版本号,例如如果你package.json 中的version 为 1.0.0, 那么执行后版本号则是:1.0.1。自定义可以通过:

$ standard-version -r minor
# output 1.1.0
$ standard-version -r 2.0.0
# output 2.0.0
$ standard-version -r 2.0.0-test
# output 2.0.0-test

需要注意的是,这里的版本名称不是随便的字符,而是需要遵循语义化版本( semver) 规范的

--prerelease, -p 预发版本命名

用来生成预发版本, 如果当期的版本号是 2.0.0,例如

$ standard-version --prerelease alpha
# output 2.0.0-alpha.0
--tag-prefix, -t 版本 tag 前缀

用来给生成 tag 标签添加前缀,例如如果前版本号为 2.0.0,则:

$ standard-version --tag-prefix "stable-"
# output tag: stable-v2.0.0

以上这几个参数可能我们用的比较多,还有其他选项可以通过 standard-version --help查看。

集成 npm

最后记得把命令集成到 npm package.json的 scripts 中, 并配合 shell 脚本使用, 如下:

"scripts": {
"release": "./scripts/release.sh",
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md && npm run changeissueurl",
"changeissueurl": "replace 'https://github.com/myproject/issues/' 'https://redmine.example.com/' CHANGELOG.md"
}, // 配置好后使用 npm run 执行发布
$ npm run release

添加 release.sh 脚本:

#!/bin/bash

# Release branch
master="master"
prefix="DTinsight_v" git pull origin $master
echo "Current pull origin $master." # Auto generate version number and tag
standard-version -r $release --tag-prefix $prefix git push --follow-tags origin $master echo "Git push origin $master"
echo "Release finished."

上面的脚本只是做了简单的分支 pull, 执行 standard-version 和最后的版本 push 工作,如果要做一些定制化的执行参数,则需要做定制修改了。

最后

项目的工程化是一件很有意思的事情,通过自动化的工具,可以有效提升项目可维护性和质量,并且避免很多不确定因素。如果你工作中发现了这些问题,而不想继续通过人肉的方法解决这些问题的话,那就赶紧试试~

原文地址:http://imziv.com/blog/article/index.htm

git commit 、CHANGELOG 和版本发布的标准自动化的更多相关文章

  1. 比较git commit 两个版本之间次数

    #!/bin/bash f1="$1*" f2="$2*" echo "第一个版本:"$f1 echo "第二个版本:" ...

  2. Git commit message和工作流规范

    目的 统一团队Git commit日志标准,便于后续代码review,版本发布以及日志自动化生成等等. 统一团队的Git工作流,包括分支使用.tag规范.issue等 Git commit日志参考案例 ...

  3. Git使用详细教程(3):git add, git commit详解

    在使用git之前,我们首先要初始化一个git管理的仓库,这里以博客(blog)为例 git init blog 我们进入目录,执行git status查看git状态,可以看到一个新的git管理的项目目 ...

  4. 规范git commit提交记录和版本发布记录

    在开发过程中我们一般都会用到git管理代码,在git commit提交代码时我们一般对git commit message随便写点简单的描述,可是随着项目参与人数的增多,发现提交的commit记录越来 ...

  5. git使用总结(包含git commit message 和 changelog 工具的介绍)

    [git的配置] 1.配置用户名和邮箱: 分为全局配置和局部配置 --system 系统配置  --global 全局配置    --local 局部配置 Git读取时:优先从local>glo ...

  6. linux显示git commit id,同时解决insmod模块时版本不一致导致无法加载问题

    linux内核默认会包含git的commit ID. 而linux的内核在insmod模块时,会对模块和内核本身的版本做严格的校验.在开发产品时,改动内核后,由于commit ID变更,会导致linu ...

  7. Git commit 信息标准和丢弃必须要的commit

    /***************************************************************************** * Git commit 信息标准和丢弃必 ...

  8. 如何写好 Git commit messages

    导语:任何软件项目都是一个协作项目,它至少需要2个开发人员参与,当原始的开发人员将项目开发几个星期或者几个月之后,项目步入正规.不过他们或者后续的开发人员仍然需要经常提交一些代码去修复bug或者实现新 ...

  9. Git 分支(分布式版本控制系统)

    前言 几乎所有的版本控制系统都以某种形式支持分支.使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线.在很多版本控制系统中,这是一个略微低效的过程--常常需要完全创建一个源代码目录的 ...

随机推荐

  1. iOS开发利器-CocoaPods安装和使用教程

    新博客http://www.liuchendi.com 开发iOS项目时肯定会用到许多第三方项目,比如说:ASIHttprequest,JSONKit等等,一些类库可能又关联着其他类库,如果超过一定的 ...

  2. 定时任务框架-quartz 时间配置

    quartz定时任务时间设置: 这些星号由左到右按顺序代表 : * * * * * * * 格式: [秒] [分] [小时] [日] [月] [周] [年] * 表示所有值. 例如:在分的字段上设置 ...

  3. Android 卡顿优化 3 布局优化 工具 Hierarchy Viewer

    欲善其事, 先利其器. 分析布局, 就不得不用到Hierarchy Viewer了. 本文工具使用皆以GithubApp的详情界面RepoDetailActivity为例说明. 为了不影响阅读体验, ...

  4. 深入C(关键字)

    C语言标准定义的32个关键字 关键字 意 义 auto 声明自动变量,缺省时编译器一般默认为auto int 声明整型变量 double 声明双精度变量 long 声明长整型变量 char 声明字符型 ...

  5. python读取大文件的方法及mmap内存映射模块

    python计算文件的行数和读取某一行内容的实现方法 :最简单的办法是把文件读入一个大的列表中,然后统计列表的长度.如果文件的路径是以参数的形式filepath传递的,那么只用一行代码就可以完成我们的 ...

  6. 18.并发类容器MQ

    package demo7.MQ; public class QueueData { private int id; private String name; private String taskC ...

  7. iconv的安装和使用

    一.Linux下iconv的安装包的下载页面http://www.gnu.org/software/libiconv/ $ ./configure --prefix=/usr/local$ make$ ...

  8. RenderMonkey 练习 第二天 【opengl 光照模型】

    光照模型 3D渲染中, 物体表面的光照计算公式为: I = 环境光(Iambient) + 漫反射光(Idiffuse) + 镜面高光(Ispecular); 其中,环境光(ambient)计算公式为 ...

  9. Java读写二进制文件示例

    相对于文本文件,二进制文件读写快,定位快而准,下面是代码示例: import java.io.DataInput; import java.io.DataOutput; import java.io. ...

  10. 近期写的一个控件——Well Swipe beta 1.0

    原文地址:http://blog.csdn.net/u013045971/article/details/51119507 近期花了大概一个半月的业余时间写的.从没有到有,中间也碰到了非常多的坑,一点 ...