git批量删除已合并分支的脚本【实战】

能安全批量删除已合并分支，但必须分清本地/远程、基准分支、保护分支三类边界

清理Git仓库里那些已经完成使命的分支，是保持代码库清爽的常规操作。批量删除听起来高效，但操作不当，轻则报错，重则可能误删关键分支。核心原则就一条：必须清晰界定本地与远程、基准分支以及保护分支这三类边界。只要边界没划清，误删和报错几乎是必然的。

git branch --merged 为什么常漏掉某些已合并分支

很多开发者第一次尝试批量删除时，都会遇到一个困惑：明明有些分支已经合并了，为什么git branch --merged没列出来？

问题出在基准上。默认情况下，git branch --merged检查的是哪些分支已经合并到了当前HEAD（即你所在的分支）。如果你正在develop分支上执行，它列出的就是“已合并进develop”的分支，而不是你以为的“已合并进主干”的分支。

• 正确做法是指定明确的基准：例如使用git branch --merged main（Git 2.22+版本）或者更通用的git branch --merged origin/main。
• 注意远程状态同步：使用origin/main这类远程追踪分支作为基准前，务必先执行git fetch，否则可能会漏掉那些刚刚在远程合并、但本地尚未拉取最新状态的分支。
• 警惕非快进合并：--merged指令无法识别Fast-forward合并之外的“逻辑合并”，比如Squash Merge。采用这种方式合并的分支，不会被标记为“已合并”，自然也不会出现在待删除列表里。

本地分支批量删除命令及避坑点

清理本地分支最经典的一行命令组合如下：

git branch --merged main | grep -v "^[[:space:]]*main$" | xargs -r git branch -d

这条命令看似简单，但每个环节都有讲究，稍不注意就会踩坑：

• 精准过滤基准分支：grep -v "^[[:space:]]*main$"比简单的grep -v "main"安全得多。后者会误杀所有包含“main”字样的分支（比如feature-main-fix），而前者通过正则表达式精确匹配行首行尾，只排除名为main的分支本身。
• 处理空输入：xargs -r参数是关键，它确保当过滤后列表为空时，不会去执行git branch -d命令，从而避免报错。需要注意的是，macOS自带的xargs可能不支持-r选项，可以通过brew install findutils安装GNU版本来解决。
• 理解删除错误：如果遇到error: The branch 'xxx' is not fully merged的提示，说明Git认为该分支的更改并未完全合并到基准分支。这时-d（小写d）会拒绝删除。如果你确认可以删除，需要单独使用强制删除命令git branch -D xxx。
• 保护关键分支：务必在命令链中增加过滤，排除像master、develop、release/*这类受保护的分支，例如：| grep -vE "^(master|develop|release/)"。

远程分支不能靠本地命令自动同步删

删除了本地分支，远端的“幽灵”分支依然存在。清理远程分支需要显式地推送删除指令，命令如下：

git branch -r --merged origin/main | sed 's/origin\///' | grep -vE '^(main|master|develop)$' | xargs -r -I {} git push origin --delete {}

执行远程删除时，有几个硬性限制必须遵守：

• 基准必须是远程追踪分支：git branch -r --merged后面跟的基准只能是像origin/main这样的远程追踪分支，直接写main是无效的。
• 处理分支名前缀：sed 's/origin\///'这一步是为了剥离origin/前缀，得到纯净的分支名。否则，你会得到类似git push origin --delete origin/feat/login的错误命令。
• 权限问题：部分Git服务器（如某些配置下的私有GitLab）可能禁止通过--delete推送删除操作。此时需要检查用户权限，或者转而使用仓库提供的API进行删除。
• 清理本地缓存：成功删除远程分支后，你本地的origin/xxx引用并不会自动消失。需要后续执行git fetch --prune或git remote prune origin来同步清理这些过时的远程追踪引用。

用 shell 函数封装成可复用命令

对于这类高频且容易出错的复杂操作，最好的办法是将其封装成可复用的Shell函数，放进你的~/.zshrc或~/.bashrc配置文件里。下面是一个增强安全性的例子：

gbclean() {
  local base=${1:-main}
  echo "? 查找已合并到 $base 的本地分支..."
  git branch --merged "$base" | grep -v "^[[:space:]]*$base$" | grep -v "^*" | sed 's/^[[:space:]]*//'
  echo -n "⚠️  确认删除？[y/N] "
  read -r confirm
  [ "$confirm" = "y" ] || [ "$confirm" = "Y" ] && \
    git branch --merged "$base" | grep -v "^[[:space:]]*$base$" | grep -v "^*" | sed 's/^[[:space:]]*//' | xargs -r git branch -d
}

使用时，只需输入gbclean main或gbclean develop即可。这种封装的核心价值在于：

• 强制交互确认：无论脚本逻辑多严谨，人工确认环节都不可省略。分支命名冲突、网络延迟、权限临时变更都可能导致意外，一个确认提示是最后的安全阀。
• 隔离远程操作：这个函数只处理本地分支，不自动触碰远程。将本地与远程清理分离，能有效避免一次误操作就波及整个团队协作环境。
• 提供预览清单：先列出将要删除的分支，让你有机会快速扫描一遍，检查是否混入了像hotfix/这类可能敏感的分支。

说到底，批量删除分支最棘手的部分，从来不是命令的语法。真正的风险在于，你是否记得在执行前看一眼git branch -vv的输出，确认那些标记着[gone]的远程分支是否真的该删；或者，团队里是否有人上周刚推送了一个release/v2.3.0到远端，但还没来得及合并进main。这些上下文信息，再聪明的脚本也无法替你把握。