如何通过semantic-release升级旧版本号？GitHub旧版本修复操作问询

针对你当前master分支已处于v2.0.1、需要为v1.0.1发布修复版本的场景，不需要将旧版本修复分支合并到master，而是通过独立的维护分支管理旧版本迭代，具体操作步骤如下：

1. 创建v1.x维护分支 #

从v1.0.1标签创建专门的维护分支（建议用1.x而非固定版本号，方便后续多次修复迭代）：

git checkout v1.0.1
git checkout -b 1.x

2. 在维护分支上修复bug #

在1.x分支上完成bug修复，提交代码时遵循semantic-release的提交规范（修复类提交用fix: 描述修复内容），示例提交命令：

git add .
git commit -m "fix: 修复xxx场景下的参数解析错误"

3. 配置semantic-release支持旧版本分支 #

修改项目的semantic-release配置文件（如.releaserc.json或package.json中的release字段），添加1.x分支的版本范围规则，确保该分支只发布1.x系列版本：

{
  "branches": [
    "master",
    {
      "name": "1.x",
      "range": "1.x",
      "prerelease": false
    }
  ]
}

4. 调整CI/CD工作流支持多分支触发 #

如果使用GitHub Actions作为CI/CD，修改工作流文件（如.github/workflows/release.yml），让1.x分支推送时也触发semantic-release：

on:
  push:
    branches:
      - master
      - 1.x

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0 # 必须拉取完整提交历史，供semantic-release分析
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npx semantic-release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

5. 推送分支触发自动发版 #

将修复后的1.x分支推送到GitHub：

git push origin 1.x

semantic-release会自动分析提交类型，将版本升级到1.0.2（修复类提交触发patch版本升级），并自动生成GitHub Release、更新项目版本号（如package.json中的version字段）。

后续维护说明 #

• 每次需要修复v1.x版本，直接切换到1.x分支，提交修复后推送即可，semantic-release会继续发布1.x系列版本（如feat类型提交会升级到1.1.0）
• 不要将1.x分支合并到master，因为v2版本是不兼容的大版本，旧版本修复逻辑可能不适用于v2分支，强行合并会导致代码冲突或功能异常

内容的提问来源于stack exchange，提问作者Akash Salunkhe