Git 不支持合并后自动清理远程分支的原生配置，真正可行的是将清理嵌入协作流程；git remote prune origin 仅删除远程跟踪引用，不删本地分支，需配合 git fetch --prune origin 使用；git-sweep cleanup 是最接近自动化的成熟工具，支持预览、确认和跳过保护分支。
Git 本身不提供“合并后自动清理远程分支”的原生配置，所有所谓“自动”都依赖外部工具或手动触发流程。真正能落地的，是把清理动作嵌入日常协作节奏里，而不是指望 Git 自己记着删。
git remote prune origin 只清远程跟踪引用，不碰本地分支
执行 git remote prune origin 后，git branch -r 里那些 origin/feature/x 消失了，但 git branch 里的 feature/x 还在——这是设计使然，不是 bug。它只删 .git/refs/remotes/origin/feature/x，不删 .git/refs/heads/feature/x。
- 必须先确认远程分支真被删了（比如 GitHub 上已不可见），否则
prune什么也不做 - 如果很久没
git fetch，prune会基于过期快照操作，可能漏删；推荐直接用git fetch --prune origin代替分开执行 -
git remote prune --dry-run origin可预览将删哪些远程跟踪引用，建议每次清理前跑一遍
git-sweep cleanup 是目前最接近“自动”的方案
git-sweep 不是 Git 内置命令，但它是唯一把“查已合并 + 删远程分支 + 询问确认”打包成单命令的成熟工具。它默认拉取最新远程状态，再比对 origin/main（或你指定的基准）是否已合并。
- 安装后直接运行
git-sweep cleanup，它会列出待删的远程分支并等待你输入yes - 想跳过确认？加
--force，但别在 CI 或共享脚本里无条件启用 - 主分支不是
main？用--master=develop；远程名不是origin？用--origin=upstream - 某些分支要保留（如
release/v2.0）？加--skip=release/v2.0
不能靠 git config 开关实现全自动清理
Git 没有类似 gc.auto 那样的 branch.autoclean 配置项。有人尝试用 git config --global alias.prune-all '!git fetch --prune && git branch --merged main | grep -v "^main$" | xargs -r git branch -d'，但这存在硬伤：
-
git branch --merged main只看本地 commit DAG，不校验远程是否真删了该分支 - 管道里
xargs git branch -d会因当前分支在列表中而失败，必须显式排除 - Windows PowerShell 不支持
xargs，得改写成ForEach-Object循环，跨平台维护成本高 - 误删风险高：如果某分支只合了一半（比如 cherry-pick 了部分提交），
--merged仍可能判定为“已合并”
真正的自动化要靠 CI/CD 流程卡点
最稳妥的“自动清理”，是把删除动作放在 PR/MR 关闭后的 CI 步骤里，由服务端触发：
- GitHub Actions 可监听
pull_request.closed事件，检查merge_commit_sha是否在main的祖先链上，再调用git push origin --delete ${{ github.head_ref }} - GitLab CI 可用
rules: if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_EVENT_TYPE == "merge"'触发清理 - 关键前提：必须确保该分支确实已被合并（不是 close without merge），且没有其他 MR 正在基于它开发
- 本地开发机永远不该承担“自动删远端”的责任——那是中央仓库的权限边界问题
容易被忽略的是：远程分支删了，但 CI 系统缓存、IDE 分支下拉列表、甚至 Bash 补全历史里还留着旧名。这些残留不会影响 Git 功能，但会干扰人眼判断——清理完远程，顺手跑一遍 git fetch --prune 和 git clean -f -d -X（慎用）才算是真的“干净”。
