GitLab流水线运行时如何禁用master分支的推送、合并与拉取？

一、你的锁定/解锁分支方案完全可行 #

这是解决这类「部署期间分支变更风险」问题的常规方案，核心是在流水线启动时锁定master分支，禁止所有推送/修改操作，部署完成（无论成功或失败）后再解锁，确保部署过程中使用的是固定版本的代码。

具体实现（分主流Git平台） #

GitLab

• 锁定阶段：在流水线开头添加步骤，用GitLab CLI或API锁定分支：

  # 用GitLab CLI
  glab repo lock --branch master --repo <owner>/<repo>
  # 或用API（需提前配置私有令牌）
  curl --request POST \
    --header "PRIVATE-TOKEN: $CI_JOB_TOKEN" \
    "$CI_API_V4_URL/projects/$CI_PROJECT_ID/protected_branches/master/lock"
  

• 解锁阶段：在流水线的收尾步骤（包括失败场景）添加解锁操作，比如用after_script确保无论流水线成功与否都执行：

  # GitLab CLI
  glab repo unlock --branch master --repo <owner>/<repo>
  # 或API
  curl --request POST \
    --header "PRIVATE-TOKEN: $CI_JOB_TOKEN" \
    "$CI_API_V4_URL/projects/$CI_PROJECT_ID/protected_branches/master/unlock"
  

• 注意：确保流水线运行账号拥有分支保护管理权限，避免因权限不足导致锁定失败。

GitHub

GitHub没有直接的「分支锁定」功能，但可以通过临时修改分支保护规则实现：

• 锁定前备份规则：流水线启动时先保存当前的分支保护配置：

  gh api repos/<owner>/<repo>/branches/master/protection > protection-backup.json
  

• 锁定阶段：更新分支保护规则，移除所有允许推送的用户/团队：

  gh api repos/<owner>/<repo>/branches/master/protection -X PATCH \
    -f "restrictions/users[]=" \
    -f "restrictions/teams[]="
  

• 解锁阶段：恢复之前备份的规则：

  gh api repos/<owner>/<repo>/branches/master/protection -X PATCH --input protection-backup.json
  

• 同样要在after_script中执行解锁，避免异常导致权限无法恢复。

二、其他替代思路 #

如果不想锁定master分支影响日常开发，还有以下几种方案：

1. 基于固定提交哈希的快照部署 #

• 流水线启动时，先记录当前master分支的HEAD提交哈希：

  COMMIT_HASH=$(git rev-parse origin/master)
  echo "部署基于提交：$COMMIT_HASH"
  

• 后续所有测试、推送操作都基于这个固定的哈希值，比如：

  git checkout $COMMIT_HASH
  # 执行测试、推送远程分支等操作
  

• 优势：完全不影响master分支的正常推送，即使期间有新代码提交，流水线仍使用启动时的快照版本部署，避免未测试代码流出；实现简单，无需额外权限配置。
• 劣势：如果部署期间有紧急修复需要立即上线，需手动触发新流水线，正在运行的流水线不会自动同步最新代码。

2. 用中转分支隔离部署流量 #

• 创建专门的部署中转分支（比如deploy-release），流水线逻辑调整为：
  1. 将origin/master的代码合并到deploy-release（合并前可加测试校验）
  2. 锁定deploy-release分支，从该分支推送到70个远程分支
  3. 部署完成后解锁deploy-release
• 优势：origin/master可正常接收推送，不会影响日常开发；中转分支只用于部署，风险范围更小。
• 劣势：需要额外维护中转分支，确保每次部署前都合并了最新的master代码，避免部署版本滞后。

3. 服务器端钩子阻止推送（适合自建Git服务器） #

如果使用自建Git服务器，可以通过**预接收钩子（pre-receive hook）**实现：

• 在钩子脚本中检查当前是否有部署流水线在运行（可通过CI平台的API查询流水线状态）
• 如果有正在运行的部署流水线，直接拒绝推送请求：

  # 示例伪代码
  RUNNING_DEPLOY=$(curl -s "$CI_API_URL/pipelines?status=running&name=deploy")
  if [ "$RUNNING_DEPLOY" != "[]" ]; then
    echo "错误：部署流水线正在运行，禁止修改master分支"
    exit 1
  fi
  

• 优势：从根源阻止不合规推送，无需手动锁定分支；
• 劣势：仅适用于自建Git服务器，托管平台（GitHub/GitLab）无法直接配置自定义预接收钩子。

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