持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第4天，[点击查看活动详情] (juejin.cn/post/714765… "juejin.cn/post/714765…")
### 语义版本控制是一种版本控制方案，旨在一目了然地传达版本之间的兼容性级别。
软件在不断变化——从发布的那一刻起，它就开始变得过时。用户需要源源不断的补丁流并需要新功能。同时，人们讨厌更新引入了重大更改，尤其是当他们没有被告知时。
使用版本号和代号来跟踪版本一直是一种常见的做法。许多项目都有递增序列（MS-DOS 6.2、6.21、6.22）；也有人使用部分发布日期（Ubuntu 18.04、20.04、22.04）。所有这些版本控制方案的主要问题是无法传达版本的兼容性。我们唯一的办法就是挖掘变更日志。
什么是语义版本控制？
语义版本控制是一种版本控制方案，旨在一目了然地传达版本之间的兼容性级别。它使用三部分编号系统：major. minor. patch（例如 1.2.3）。并且有时带有特殊标识符后缀，例如-alpha或-rc1。
每个部分都有不同的含义：
Major : 增加这个数字 (1.0.0 -> 2.0.0) 表示用户应该期待重大的重大变化。
Minor：次要编号 (1.0.0 -> 1.1.0) 在发布非破坏性功能和更改时递增。次要版本应该是向后兼容的。
补丁：补丁级别的更改 (1.0.0. -> 1.0.1) 是一种非破坏性升级，它引入了低风险更改，例如修复错误或修补安全问题。
开发人员可以通过比较版本号来快速评估升级风险。主要版本是有风险的，应该仔细计划。次要和补丁级别的更改引入不兼容性的可能性要低得多，并且安装起来更安全。
使用语义发布自动化版本
我们如何确定语义版本控制方案中的版本号？这是一个棘手的问题，因为一个典型的版本包含几十个提交。有些包含错误修复，而另一些可能会引入重大更改。在这种情况下，确定适当版本的唯一方法是单独审查每个提交并评估影响。如果听起来很多重复且容易出错的工作最好使用一些自动化工具来完成，那么你是对的。
Semantic-release是一个版本控制工具，能够通过读取提交消息来计算语义版本号。它还可以生成发布说明并将包发布到 GitHub 和 NPM。
正如您可能想象的那样，要使其正常工作，提交消息应遵循预定义的模式：
<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
标头是消息的唯一强制性部分，应采用如下格式：
<type>(<scope>): <short summary>
标头中最重要的组成部分是类型，它有助于语义发布评估提交中引入的更改的重要性。默认行为遵循Angular 的消息格式：
| 标题类型 | 结果 |
|---|---|
| fix, perf | Bump version to the next patch level (1.0.0 -> 1.0.1) and release |
| feat | Bump version to the next minor level (1.0.0 -> 1.1.0) and release |
| docs, build, ci, refactor, test | No version bump. No release. |
如何开始使用语义发布
虽然语义发布是基于节点的应用程序，但它支持任何语言，而不仅仅是 JavaScript 或 TypeScript。不过，您需要安装 Node 和 NPM 才能使用它。
1.要将语义发布添加到您的项目，请执行以下步骤：
使用npx semantic-release-cli setup. 当询问要使用哪个 CI 平台时，选择Other并复制显示的环境变量。您将获得一个用于 GitHub 的令牌，也可以选择获得一个用于 NPM 的令牌。
export GH_TOKEN=ghp_Lw83uUpu4paBlLKQuRijD3NMTDusAL07J89l
export NPM_TOKEN=npm_xWtDqAasy9yBTPPuA6QppCJx7JIu5w1009KY8
2.转到项目的 Git 存储库。如果项目在 Node.js 上运行，请添加semantic-release包：
npm --save-dev semantic-release
3.按照之前讨论的提交指南进行一些代码更改并创建提交。例如：
feat: initial commit
4. 运行npx semantic-release。在非 CI 环境中，该工具以试运行模式运行。该日志显示将在下一个版本中分配的版本（在下面的示例中，v1.0.0）。
ℹ Running semantic-release version 19.0.5
⚠ This run was not triggered in a known CI environment, running in dry-run mode.
✔ Allowed to push to the Git repository
✔ Completed step "verifyConditions" of plugin "@semantic-release/npm"
✔ Completed step "verifyConditions" of plugin "@semantic-release/Github"
ℹ No git tag version found on branch master
ℹ No previous release found, retrieving all commits
ℹ There is no previous release, the next release version is 1.0.0
ℹ Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
✔ Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
⚠ Skip v1.0.0 tag creation in dry-run mode
ℹ Release note for version 1.0.0:
# 1.0.0 (2022-08-23)
### Features
* initial commit
5. 当您准备好发布时，执行：npx semantic-release --no-ci。这将标记发布并发布包。
您可以通过在项目的根目录中创建一个.releaserc或文件来自定义工具的行为。release.config.js这将允许您调整提交消息格式，将能够触发发布的分支列入安全列表，并启用可选插件。
结论
保持一致的版本号将帮助您获得用户和其他开发人员的信任。简单的项目可能只需要手动版本控制，但具有多个贡献者的高度活跃的代码库不会容忍这种情况。唯一明智的选择是自动化发布工作，并使用语义发布等工具从中间移除人为因素。
