基于GH Actions的Rebase与部署触发异常问题咨询

方法1：添加工作流执行条件，仅处理分支顶端的提交 #

修改你的deployment.yml，在部署job中添加条件判断，仅当触发工作流的提交是当前分支的最新提交时才执行部署步骤。这样可以避免因Rebase导致的历史提交触发其他分支的工作流。

修改后的配置如下：

name: Run deploy

on:
  workflow_dispatch:
  push:
    branches:
      - main
      - staging
      - dev

jobs:
  deploy:
    runs-on: ubuntu-latest
    # 仅当触发提交是当前分支的最新提交时执行
    if: github.sha == github.event.head_commit.id
    steps:
      # 你的构建、部署步骤（保留原步骤即可）
      - name: Checkout code
        uses: actions/checkout@v4
      # 后续构建镜像、部署等步骤...

原理说明 #

当你将staging基于dev Rebase后推送时，staging分支的最新提交会触发工作流，此时github.sha（触发工作流的提交哈希）与github.event.head_commit.id（推送事件中分支的最新提交ID）完全一致，条件成立，部署正常执行。而dev分支的工作流若被误触发，触发的提交是dev历史中的旧提交，与dev当前的最新提交ID不匹配，条件不成立，部署步骤会被跳过。

方法2：利用并发组避免异常状态（辅助方案） #

如果希望即使工作流被误触发，也不会出现状态继承等异常，可以添加concurrency配置，确保同一分支同时只运行一个工作流实例，新的实例会自动取消旧的实例。

在jobs上方添加如下配置：

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

完整配置示例：

name: Run deploy

on:
  workflow_dispatch:
  push:
    branches:
      - main
      - staging
      - dev

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    if: github.sha == github.event.head_commit.id
    steps:
      # 你的构建、部署步骤...

操作注意事项 #

推送Rebase后的staging分支时，建议使用git push origin staging --force-with-lease，避免强制推送覆盖他人未同步的修改，同时确保仅推送staging分支，不要误推dev分支。

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