项目版本管理自动化及工具使用的方法

htzyl206
272 阅读10分钟

项目版本自动生成流程调研

现在最流行的版本管理工具非git莫属，而项目版本号的自动生成changlog及版本号，前期就是要有良好的代码提交规范，有助于项目的维护，为了防止一些不规范的代码 commit并push到远端,我们可以在git命令执行前用一些钩子来检测并阻止。

一、环境与工具

  1. 安装node.js - Node.js 是一个基于 Chrome V8 引擎的 JavaScript 运行环境
  2. git- 开源的分布式版本控制系统
  3. husyk - git commit前做一些操作，如eslint，提交规范检查等等；
  4. commitlint - 规范了 commit 可以更清晰的查看每一次代码提交记录，还可以根据自定义的规则，自动生成 changeLog 文件
  5. standard-version - 自动升级版本 - 自动打tag - 自动生成changelog

二、nodejs安装及使用

Node.js 是一个基于 Chrome V8 引擎的 JavaScript 运行环境

1.Node.js官网下载

根据自身系统下载对应的安装包

2.安装

双击安装包，点击Next，勾选使用许可协议，点击Next，选择安装位置（可根据个人情况更换路径），继续点击Next，点击Next，点击Install，点击Finish完成安装。

3.添加环境变量

​ 3.1 进入环境变量，编辑【系统变量】下的变量【Path】

​ 3.2 添加Node.js的安装路径

4.验证是否在安装成功

​ 进入cmd命令行窗口，输入node -v查看nodejs版本

node -V

​ 输入npm -v查看npm版本

npm -V

三、git安装及使用

开源的分布式版本控制系统

1.Git的安装

官网下载地址：git-scm.com/download

2.使用详情

网上百度

四、husyk的安装及使用

husky能够防止不规范代码被commit、push、merge等等。

git commit前做一些操作，如eslint，提交规范检查等等；

1. 安装
npm i lint-staged -D  # 安装lint-staged
npm i husky -D  # 安装husky
# 或者
yarn add lint-staged husky -D
2. 创建.husky/目录并指定该目录为 git hooks 所在的目录

在 pacakge.json 中添加prepare脚本

  • 使用命令的方式添加
npm set-script prepar "husky install"

提示

命名方式添加需要npm版本在 7.x+

  • 手动在 package.json 中添加
{
  "scripts": {
    "prepare": "husky install"
  }
}

prepare 脚本会在执行 npm install 之后自动执行。也就是说当我们执行 npm install 安装完项目依赖后会执行 husky install 命令。

添加好脚本命令后 初始化 husky

npm run prepare # 初始化husky,将 git hooks 钩子交由,husky执行
3.添加 git hooks

创建一条pre-commit hook

npx husky add .husky/pre-commit "npx lint-staged"

执行命令后 .husky/目录下新增一个名为pre-commit的 shell 脚本 在知道后执行git commit命令的时候就会执行这条脚本

生成的 shell 脚本如下(自动生成)

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx lint-staged

五：commitlint 安装与使用

 在多人协作的背景下，git 仓库和 workflow 的作用很重要。而对于 commit 提交的信息说明存在一定规范，现使用 commitlint + husky 规范 git commit -m "" 中的描述信息。

一句话说，当我们运行 git commmit -m 'xxx' 时，用来检查 xxx 是否满足固定格式的工具。

我们都知道，在使用 git commit 时，git 会提示我们填入此次提交的信息。

可不要小看了这些 commit，团队中规范了 commit 可以更清晰的查看每一次代码提交记录，还可以根据自定义的规则，自动生成 changeLog 文件。

1. 在项目中安装

安装commitlint用于commit操作的规范检测 安装@commitlint/config-conventional用于commitlint的一个检测标准

npm i @commitlint/cli @commitlint/config-conventional -D

# 或者
yarn add @commitlint/cli @commitlint/config-conventional -D
2.添加 commitlint 配置

根目录创建commitlint.config.js配置文件 并写入规则 使用@commitlint/config-conventional规则

@commitlint/config-conventional 这是一个规范配置,标识采用什么规范来执行消息校验, 这个默认是 Angular 的提交规范

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
3.husyk 中添加 commit-msg
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

执行命令后 .husky/目录下新增一个名为commit-msg的 shell 脚本

// commit-msg脚本内容
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx --no-install commitlint --edit "$1"

当执行git commit命令提交commit-msg就会触发 git hook 并执行上述脚本

4.Commitlint 提交规范

commitlint 推荐我们使用 config-conventional 配置去写 commit

  • 提交格式**（注意冒号后面有空格）**

    git commit -m <type>[optional scope]: <description>

    type ：用于表明我们这次提交的改动类型，是新增了功能？还是修改了测试代码？又或者是更新了文档？

    optional scope：一个可选的修改范围。用于标识此次提交主要涉及到代码中哪个模块。

    description：一句话描述此次提交的主要内容，做到言简意赅。

  • 常用的 type 类型

    类型描述
    build编译相关的修改，例如发布版本、对项目构建或者依赖的改动
    chore其他修改, 比如改变构建流程、或者增加依赖库、工具等
    ci持续集成修改
    docs文档修改
    feat新特性、新功能
    fix修改bug
    perf优化相关，比如提升性能、体验
    refactor代码重构
    revert回滚到上一个版本
    style代码格式修改, 注意不是 css 修改
    test测试用例修改

  • 例子

    git commit -m 'fix(account): 修复xxx的bug'
git commit -m 'refactor: 重构整个项目'
5. 安装辅助提交依赖（commitizen）

当有了 commitlint 检查提交规范 如果手动提交就比较麻烦 这里就可以借助工具commitizen

Simple commit conventions for internet citizens.

npm i commitizen cz-conventional-changelog -D  # 安装commitizen依赖
# 或者
yarn add commitizen cz-conventional-changelog -D

安装好相关依赖后 需要在package.json进行配置

{
    "script": {
        "commit": "cz"  // 添加提交指令 使用cz提交
    }
    "config": {
        "commitizen": {
            "path": "cz-conventional-changelog" // 使用这个依赖提供的预设
        }
    }
}

测试

当依赖安装好并且进行了以上配置 就可以运行npm run commit进行测试

使用cz进行提交 会出现选项供我们选择

git-cz

当此次提交类型选定后 就需要填写本次提交的短描述与长描述等相关信息

git-cz-1

6. 添加 commitizen 的自定义提示信息

安装cz-customizable,安装这个依赖后就可以自定义提示内容 可以自定义中文或者加上一些 emoji

npm i cz-customizable -D

# 或者
yarn add cz-customizable -D

当cz-customizable安装好之后 就需要在packgae.json中的commitizen配置

{
  "config": {
    "commitizen": {
      "path": "node_modules/cz-customizable" // 将提示信息依赖修改成cz-customizable
    }
  }
}

经过上面的配置 就可以自定义提示信息了

这就需要新增一个自定义内容文件

touch .cz-config.js

.cz-config.js文件就是用来自定义提示信息

// .cz-config.js 示例
module.exports = {
  allowBreakingChanges: ["feat", "fix"],
  allowCustomScopes: true,
  scopes: [],
  types: [
    {
      name: "功能：新增功能，迭代项目需求 (feat)",
      value: "feat",
    },
    {
      name: "修复：修复缺陷，修复上一版本存在问题 (fix)",
      value: "fix",
    },
    {
      name: "文档：更新文档，仅改动文档不改动代码 (docs)",
      value: "docs",
    },
    {
      name: "样式：变动格式，不影响代码逻辑 (style)",
      value: "style",
    },
    {
      name: "重构：重构代码，非新增功能也非修改缺陷 (refactor)",
      value: "refactor",
    },
    {
      name: "性能：优化性能，提高代码执行性能 (perf)",
      value: "perf",
    },
    {
      name: "测试：新增测试，追加测试用例验证代码 (test)",
      value: "test",
    },
    {
      name: "构建：更新构建，改动构建工具或外部依赖 (build)",
      value: "build",
    },
    {
      name: "脚本：更新脚本，改动CI或执行脚本配置 (ci)",
      value: "ci",
    },
    {
      name: "事务：变动事务，改动其他不影响代码的事务 (chore)",
      value: "chore",
    },
    {
      name: "回滚：回滚版本，撤销某次代码提交 (revert)",
      value: "revert",
    },
    {
      name: "合并：合并分支，合并分支代码到其他分支 (merge)",
      value: "merge",
    },
    {
      name: "同步：同步分支，同步分支代码到其他分支 (sync)",
      value: "sync",
    },
    {
      name: "改进：改进功能，升级当前功能模块 (impr)",
      value: "impr",
    },
  ],
};

测试

自定义提示配置好了 我们可以尝试npm run commit提交一下

就可以看到我们自定义的提示内容设置成功了

git-cz-2

7：常见问题
  1. 自定义的提示信息 提交为什么无法通过 commitlint 校验？

由于我们自定义了提示信息和规则 这时候可能就没办法通过@commitlint/config-conventional的校验

这个时候我们就需要安装commitlint-config-cz 让commitlint使用cz的规范

npm i commitlint-config-cz -D
# 或者
yarn add commitlint-config-cz -D

当安装好依赖后 需要修改.commitlintrc.js文件夹

module.exports = {
  "extends": ["cz"],
  "rules": {}, // 这里可以配置规则 类似于eslint的配置
};

使用 commitlint 可以规范我们每一次的 commit，我们可以用来自动生成 changeLog 等文件，方便代码管理。

六、standard-version版本自动化工具

1：介绍

是一款遵循语义化版本（semver）和 commit message 标准规范的版本自动化工具，它还可以使生成 changelog 自动化。并且将我们符合 Conventional Commits 规范的提交信息格式化。

2：作用
  • 自动升级版本
  • 自动打 tag
  • 自动生成 changelog
3：安装

使用前提

在使用 standard-version 之前，需要遵循 Conventional Commit Specifications 来进行标准化的 commit message 编写。这是因为 standard-version 是基于 commit 类型来更新版本号的（feature 会更新 minor, bug fix 会更新 patch, BREAKING CHANGES 会更新 major）。commitizen 可以帮助我们提交符合 Conventional Commit Specifications 的 commit message。

npm i standard-version -D

配置脚本

在package.json文件中添加脚本

提示

高版本可以使用npm set-script进行设置

// package.json
{
  "scripts": {
    "release": "standard-version"
  }
}
4：配置

安装好相应依赖与指令需要进行配置

增加 .versionrc 文件来格式化 log ，使我们的 changelog 根据 Conventional Commits 规范更加语义化。

{
  "header": "", // 可自定义添加生成的changelog头部内容
  "types": [
    { "type": "feat", "section": "✨ Features | 新功能", "hidder": false },
    { "type": "fix", "section": "🐛 Bug Fixes | Bug 修复", "hidder": false },
    { "type": "init", "section": "🎉 Init | 初始化", "hidder": false },
    { "type": "docs", "section": "✏️ Documentation | 文档", "hidder": false },
    { "type": "style", "section": "💄 Styles | 风格", "hidder": false },
    { "type": "refactor", "section": "♻️ Code Refactoring | 代码重构", "hidder": false },
    { "type": "perf", "section": "⚡ Performance Improvements | 性能优化", "hidder": false },
    { "type": "test", "section": "✅ Tests | 测试", "hidder": false },
    { "type": "revert", "section": "⏪ Revert | 回退", "hidder": false },
    { "type": "build", "section": "📦 Build System | 打包构建", "hidder": false },
    { "type": "update", "section": "🚀 update | 构建/工程依赖/工具升级", "hidder": false },
    { "type": "tool", "section": "🚀 tool | 工具升级", "hidder": false },
    { "type": "ci", "section": "👷 Continuous Integration | CI 配置", "hidder": false }
  ],
  // 跳过相关内容
  "skip": {
    "bump": false, // 是否跳过更改版本
    "changelog": false, // 是否跳过生产changelog
    "commit": false, // 是否跳过自动commit
    "tag": false // 是否跳过打tag
  }
}
  • "type" commit 类型
  • "section" 不同的 commit 类型所在 CHANGELOG.md 中的区域
  • "hidden" 是否在 CHANGELOG.md 中显示
5：使用

当一切都配置好，使用 commitlint 进行代码提交之后

将代码合并到发版分支 可执行npm run release

按默认规则升级版本号

npm run release # 执行版本更新

这个时候就会自动更改pacakge.json中的version

npm的版本号格式：major.minor.patch

手动设置版本更新

1.直接升级 major

"scripts": {
	"release-major": "standard-version --release-as major",
}

2.直接升级minor

"scripts": {
	"release-major": "standard-version --release-as minor",
}

3.直接升级patch

"scripts": {
	"release-major": "standard-version --release-as patch",
}

4.强制打一个静态版本号

"scripts": {
	"release-static": "standard-version --release-as 3.3.3",
}

5.发布第一个版本

npm run release -- --first-release

# 或者
npx standard-version --first-release
6：示例

git 提交记录

git提交记录

生成的CHANGELOG文件

生成的changelog

7：更多用法

1.首次发布，不升级版本号

yarn release -- --first-release

2. 预发版本，及前缀

yarn release -- --prerelease

假如当前版本号为 1.0.0

yarn release -- --prerelease

现在版本号为 1.0.1-0

yarn release -- --prerelease alpha // --prerelease, -p 预发版本命名

现在版本号为 1.0.1-alpha.0

3. 指定升级major/minor/patch版本号，或自定义版本号

自动根据

当自动生成的版本号不是你想要的，你可以主动指定版本号， yarn release -- --release-as

当前版本号 1.0.0

yarn release -- --release-as minor

现在版本号为 1.1.0

yarn release -- --release-as 2.2.0

现在版本号为 2.2.0

8：自动化版本流程
git pull // 拉取
// 新增内容
git add.
yarn commit
//打包版本
yarn release
avatar
文章
阅读
粉丝