开源项目常用工具对比：（一）版本管理/发布工具对比： release-it VS standard-version （优化版）

编写开源项目时，通常需要控制版本、生成CHANGELOG等内容，我们通常会借助第三方工具来完成，现在就来介绍常用的2个工具 release-it 和 standard-version.

Release-it

功能

版本管理 ：自动在 package.json 中递增版本号，支持预发布版本管理。
日志生成：自动生成变更日志，支持通过插件扩展日志格式。
Git 操作：自动执行 Git commit、tag、push 等操作，将代码推送到远程仓库。
发布流程：支持自动发布到 npm、GitHub、GitLab 等平台，创建发行版。
构建与测试：通过 Hooks 执行测试、构建等命令。
插件支持：强大的插件体系，可以扩展功能。

使用方式

安装：通过 npm 安装 release-it：
bash 复制代码
```
npm install release-it --save-dev
```

配置：在项目根目录下创建配置文件 release-it.json 或在 package.json 中添加配置项，例如：

json 复制代码

{
  "release-it": {
    "git": {
      "commit": true,
      "tag": true,
      "push": true
    },
    "npm": {
      "publish": true
    }
  }
}

运行：在 package.json 中添加脚本：
json 复制代码
```
{
  "scripts": {
    "release": "release-it"
  }
}
```
然后执行 npm run release 来触发版本发布。

应用场景

适用于需要完整自动化发布流程的项目，尤其是 npm 包、GitHub 项目等。
适合在持续集成和持续部署（CI/CD）环境中使用，提高开发团队的工作效率。

Standard-version

功能

版本号更新：根据提交信息自动更新版本号，遵循语义化版本规范。
日志生成 ：自动生成 CHANGELOG.md 文件，记录新增功能、修复的 bug 等详细信息。
Git 操作：创建 Git tag，但不会自动推送代码。
生命周期脚本 ：允许在 release 过程中执行自定义的命令，如 prebump、postbump、prechangelog 等。

使用方式

安装：通过 npm 安装 standard-version：
bash 复制代码
```
npm install standard-version --save-dev
```
配置：在项目根目录下创建配置文件 .versionrc 或在 package.json 中添加配置项，例如：
json 复制代码
```
{
  "scripts": {
    "prebump": "echo 'Running prebump script'",
    "postbump": "echo 'Running postbump script'"
  }
}
```
运行：在 package.json 中添加脚本：
json 复制代码
```
{
  "scripts": {
    "release": "standard-version"
  }
}
```
然后执行 npm run release 来触发版本发布。

应用场景

适合需要版本号更新和日志生成的项目，尤其是遵循 Conventional Commits 规范的项目。
适用于个人开发者或团队开发者，简化版本控制和发布流程。

对比总结

自动化程度

Release-it：自动化程度更高，可以完成从版本更新到代码推送、日志生成、平台发布的整个流程。
Standard-version：主要专注于版本号更新和日志生成，不会自动推送代码或发布到 npm 等平台。

灵活性和扩展性

Release-it：配置灵活，支持通过插件扩展功能，可以更好地适应不同项目的需求。
Standard-version：配置相对简单，但足以满足基本的版本管理和日志生成需求。

社区和生态

Release-it：被广泛应用于 npm 包、GitHub 项目等的自动化发布，如 Redux、Axios 等知名开源项目。
Standard-version：也具有一定的用户基础，尤其在遵循 Conventional Commits 规范的项目中。

适用场景

Release-it：如果项目需要完整的自动化发布流程，包括代码推送和平台发布，是更好的选择。
Standard-version：如果只需要版本号更新和日志生成，可以满足需求。

表格对比

以下是 release-it 和 standard-version 在版本管理和发布方面的功能对比表格：

功能/特性	release-it	standard-version
版本号升级	自动更新 `package.json` 中的版本号，支持手动指定版本号。	根据提交信息中的类型自动计算版本号。
Git 操作	自动执行 Git 提交、标签创建和推送。	使用 Git tag 为新版本打上标签。
Changelog 生成	自动生成变更日志。	自动生成和更新 Changelog。
npm 发布	支持自动发布到 npm 注册表。	支持发布到 npm 仓库。
插件扩展	支持插件扩展功能，可与多种工具集成。	支持通过生命周期脚本的高级用法进行定制。
预发布管理	支持管理 alpha、beta 和 rc 等预发布版本。	不支持预发布版本管理。
交互式体验	提供友好的命令行界面，允许用户确认每一步操作。	无交互式体验，完全自动化。
配置灵活性	支持通过配置文件进行详细定制。	支持通过配置文件（如 `.versionrc`）进行定制。
CI/CD 集成	支持从任何 CI/CD 环境进行发布。	可以集成到 CI/CD 流程中。
钩子机制	在发布流程的不同阶段执行自定义命令。	支持生命周期脚本，如 `prebump`、`postbump` 等。
适用范围	适用于各种类型的项目，不仅仅是 npm 包。	主要用于 npm 包的版本管理和发布。

综上所述，release-it 和 standard-version 都是优秀的版本管理和发布工具，各有优势。选择时可以根据项目的具体需求、团队的使用习惯以及对自动化程度的要求来决定使用哪个工具。

菲鸽 unibest 的选择

原本我想在 unibest 中引入 release-it，然后看到 wot-ui 用的是 standard-version, 于是就做了个对比。

经我调查，前端生态中 vuejs、vitejs、react 这样的项目用的都是 standard-version。

既然如此， unibest 会使用 standard-version 作为版本控制工具，敬请期待。

unibest 链接地址

文档地址：unibest.tech
github 地址：github.com/feige996/un...
gitee 地址：githee.com/feige996/un...

欢迎体验，欢迎star!

下面的是旧账号和旧文档，留个纪念。

旧的 github: github.com/codercup/un...

旧的文档地址：codercup.github.io/unibest-doc...

补充说明(2025-01-08)

1. 版本号升级规则

standard-version 是基于语义化版本控制（Semantic Versioning）和约定式提交（Conventional Commits）规范来自动升级版本号的。其升级版本号的规则如下：

主版本号（MAJOR） ：当提交信息中包含 BREAKING CHANGES 时，会升级主版本号。这通常意味着有不兼容的 API 变更。
次版本号（MINOR） ：当提交信息类型为 feat（新功能）时，会升级次版本号。这表示添加了向后兼容的新功能。
补丁版本号（PATCH） ：当提交信息类型为 fix（修复）时，会升级补丁版本号。这表示进行了向后兼容的 bug 修复。

如果当前版本号没有主版本号（例如 0.1.2），则包含 BREAKING CHANGES 的提交不会自动升级主版本号。在这种情况下，需要手动指定版本号的升级，例如使用 standard-version --release-as major 来强制升级主版本号。

2.其他分支合并过来的能否检测出来

可以的。比如 unibest 有 base main i18n 等多个分支，主要代码在 base 里面编写，然后会合并到其他所有分支，合并到 main 分支时合并的消息是 Merge branch 'base'，但是在 main 分支执行 pnpm release 时同样可以识别出 base 分支里面的提交信息，可以正常生成想要的 CHANGELOG 记录。