如何自动化阻止将master分支合并到Release相关分支？

一、用GitHub分支保护规则加一道防线 #

• 给Release分支设置专属保护规则：
  • 开启**“合并前需要PR审核”**，指定熟悉分支策略的核心成员作为必填审核人，提前拦截错误合并的PR。
  • 启用**“合并前必须通过状态检查”**，关联后续的CI检测脚本，只有检测通过的PR才能合并到Release分支。
  • 限制合并权限：通过“限制可推送至匹配分支的人员”设置，仅允许发布管理人员向Release分支合并变更，避免普通开发者直接将带有错误合并内容的开发分支合入。

二、CI集成检测脚本自动识别有害合并 #

在CI流程中加入以下检测逻辑，揪出存在问题的分支：

1. 检查是否存在合并master的记录
   用Git命令定位当前分支与Release分支基线之间的合并提交，排查是否有合并master的操作：

   # 获取Release分支基于master的基线提交
   BASE_COMMIT=$(git merge-base master Release_1.2.3)
   # 查找当前分支中合并master的提交
   git log $BASE_COMMIT..HEAD --merges --grep="Merge branch 'master'"
   

   如果存在这类合并提交，直接标记CI流程失败。

2. 检测是否有批量文件删除操作
   对比当前分支与基线提交的文件差异，识别异常的大量删除行为：

   # 统计删除的文件数量
   DELETED_FILES=$(git diff $BASE_COMMIT..HEAD --name-only --diff-filter=D | wc -l)
   # 设置阈值，比如删除超过10个文件则触发告警
   if [ $DELETED_FILES -gt 10 ]; then
       echo "错误：检测到大量文件删除，可能是错误合并后手动删除的内容"
       exit 1
   fi
   

3. 验证变更来源的合规性
   检查分支内的所有提交，确保仅包含针对Release分支的bug修复，未引入master分支的新功能变更。可通过对比文件路径、变更内容，排除属于master新功能的目录或文件。

三、从流程上阻断问题源头 #

• 要求开发者修复Release分支的bug时，必须从对应Release分支拉取修复分支，禁止从master分支拉取，从根源避免合并master的操作。
• 在CI脚本中加入分支来源检测：检查修复分支的上游是否为对应Release分支，不符合则直接拦截。

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