合并含chore(release)提交的分支后semantic-release未触发发布

核心原因分析 #

你遇到的情况主要和semantic-release的版本检测逻辑、合并提交的[skip ci]标记以及GitHub Actions触发规则相关，以下是具体排查方向：

• [skip ci]标记导致CI被跳过
  next分支最后一个提交是chore(release): 2.0.0 [skip ci]，如果合并main时用的是默认的「快进合并」，这个提交会直接同步到main分支。GitHub Actions会识别提交信息里的[skip ci]关键字，自动跳过该提交的CI流程，自然不会触发release动作。
  解决：合并时执行git merge --no-ff next创建新的合并提交，确保合并提交信息不含[skip ci]，就能正常触发CI。

• semantic-release判定版本已发布
  semantic-release通过git标签和提交记录判断是否需要发布新版本：

  1. 若next分支发布2.0.0后，你未将对应git标签推送到远程，main分支合并后虽无2.0.0标签，但semantic-release会检测到提交历史里的release记录，判定该版本已发布，不会重复触发；
  2. 若已推送2.0.0标签到远程，main分支合并后HEAD对应的提交已关联该标签，semantic-release会直接跳过发布流程。
     解决：若要在main分支重新触发2.0.0发布，可先删除本地和远程的2.0.0标签，再用不带[skip ci]的合并提交推送到main；或者在main分支新增空提交git commit --allow-empty -m "trigger release"触发CI。

• semantic-release分支配置遗漏
  检查你的semantic-release配置文件（如.releaserc或package.json的release字段），确认main分支是否在发布分支列表中，且对应发布频道为@release。如果main分支不在配置列表内，semantic-release会忽略该分支的CI触发。
  示例配置片段：

  {
    "branches": [
      "main",
      { "name": "next", "channel": "next" }
    ]
  }
  

快速验证步骤 #

1. 查看main分支最新提交信息，确认是否包含[skip ci]；
2. 执行git tag查看本地标签，git ls-remote --tags origin查看远程标签，确认2.0.0标签状态；
3. 核对semantic-release的分支配置，确保main分支在发布列表中。

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