如何通过GitHub Actions阻止PR合并，避免Master流水线版本冲突？

1. 分支保护+自定义状态检查 #

• 给master分支设置必须通过指定状态检查才能合并的保护规则。
• 开发一个简单的状态检查脚本或轻量服务：
  • 当master流水线启动时，通过GitHub API将对应状态标记为pending或失败；
  • 当流水线完成（无论成功或失败），再将状态更新为成功。
• 这样PR只有在状态检查为成功时才能合并，确保同一时间只有一个PR的后续流水线在运行。

2. CI流水线加分布式锁 #

• 在master流水线的版本升级步骤前，添加分布式锁逻辑：
  • 可以用Redis、或者基于GitHub仓库的临时文件作为锁标记（比如创建.ci-running文件，存在则表示有流水线在执行）；
  • 流水线启动时先尝试获取锁，拿不到则直接终止并提示开发者等待之前的流水线完成；
  • 流水线完成后释放锁（删除锁文件或清除Redis键）。

3. 优化版本升级逻辑，兼容并发合并 #

• 修改版本升级脚本，处理并发合并后的冲突场景：
  • 在升级版本前，先拉取最新的master代码；
  • 检测版本文件（如package.json、VERSION）是否有冲突，若有则重新计算版本号并更新；
  • 提交新版本前再次拉取最新代码，确认没有新提交后再推送。
• 这种方式不用阻止合并，而是让流水线自动处理并发带来的问题，适合能接受少量重试的场景。

4. 预合并分支+批量版本升级 #

• 让PR先合并到中间分支（如develop），而非直接合并到master；
• 定期触发（或手动触发）将develop合并到master的流水线，在这个流水线中统一执行版本升级；
• 这种方式避免了master分支的频繁并发合并，适合可以接受批量发布版本的场景。

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