如何配置持续部署触发发布流水线 实现批量PR合并后单次发版

最优轻量方案：调整CI触发规则，按需触发发布环节 #

这是改造成本最低、对贡献者完全无感知的方案，仅需修改CI配置即可：

• 保留现有PR合并到master分支的触发逻辑，但调整CI流水线的执行规则：普通合并PR到master时，仅执行代码检查、构建、测试等前置环节，跳过release/deploy相关步骤
• 新增发布触发规则：仅当master分支的提交信息包含指定关键词（比如trigger release）时，才执行完整的版本号计算、打标签、发布流程
  需要集中发布时，所有PR合并完成后，你只需在本地执行两行命令提交空提交并推送到master即可触发一次发布：

git commit --allow-empty -m "chore: trigger release"
git push origin master

其他可选方案 #

方案2：标签驱动发布 #

将CI的发布环节调整为仅响应符合语义化版本格式的新标签推送事件，平时合并PR到master仅跑前置校验流程。
需要发布时，你可以先拉取最新的master代码，执行版本号自动计算的逻辑生成标签并推送即可触发发布，也可以将版本号计算、打标签的逻辑全部放到CI中，通过推送自定义前缀的标签（比如release/*）触发完整流程。

方案3：定时自动发布 #

如果你的团队有固定的发布周期（比如每周1次、每两周1次），可以直接在CI中配置定时任务，固定在指定时间拉取当前master分支的最新代码执行发布流程，全程无需人工介入操作。

方案4：基于合并队列的批量合并 #

如果你使用的是GitHub企业版或者公开仓库，可开启GitHub Merge Queue功能，把需要集中合并的多个PR全部加入合并队列，配置队列一次性合并所有PR后仅触发一次CI流水线，就能实现合并N个PR仅生成一次版本的需求，全程操作都在GitHub界面完成。

你之前考虑的多分支方案确实会增加贡献者成本，除非你的项目有严格的日常开发/预发/生产的环境隔离要求，否则不需要采用这种重流程的方案。

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