应清理冗余分支引用：执行git branch --merged | grep -v "main\|master\|develop" | xargs git branch -d 删除已合并本地分支，再运行git remote prune origin 清理失效远程跟踪分支，并检查.git/config中重复fetch规则，必要时禁用reflog以提升性能。
git branch -a 输出成千上万个分支，切换/拉取变慢怎么办
这不是 Git 本身设计缺陷，而是分支引用（refs/heads/xxx）长期堆积后，Git 在遍历、匹配、解析 ref 时的线性开销暴涨。尤其当 git branch -a 返回上万行，git fetch 会逐个检查远程跟踪分支是否需更新，git checkout 也要扫描所有本地分支做补全提示——这些操作都卡在文件系统读取和字符串匹配上。
关键不是“删分支”，而是“删掉没用的 ref 引用”。Git 不会自动清理已合并但未删除的远程跟踪分支（origin/feature/old-thing），也不会清理被 git push --delete 删除后残留的本地 refs/remotes/origin/xxx。
- 先确认真实数量：
ls .git/refs/heads/ | wc -l和ls .git/refs/remotes/origin/ | wc -l，别只信git branch -a的输出（它可能含符号链接或损坏项） - 批量清理已合并的本地分支：
git branch --merged | grep -v "main\|master\|develop" | xargs git branch -d（注意：-d 是安全删除，-D 强制删） - 同步清理远程跟踪分支：
git remote prune origin—— 这步必须做，否则下次git fetch仍会拉下旧 ref - 如果远程仓库本身也堆了万级分支（如 CI 自动生成的 PR 分支），得联系管理员用
git update-ref -d refs/heads/xxx批量删服务端 ref，本地再prune
git fetch 很慢，且日志里反复出现 “refname 'refs/heads/xxx' not found”
这是典型“远程分支残留 + 本地 ref 同步错位”症状。Git 在 fetch 时，会把远程所有 refs/heads/* 列表下载下来，再逐个比对本地 .git/packed-refs 或 .git/refs/remotes/origin/ 下是否存在对应路径。若远程已删某分支，但本地 origin/xxx 文件还躺在那儿（哪怕内容为空），Git 就会尝试解析它，失败后打日志、重试、跳过——万级这样的“幽灵 ref”，fetch 就变成 I/O 密集型任务。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 别直接删
.git/refs/remotes/origin/下所有文件：有些可能是你手动建的 tracking 分支，删了就断连 - 正确做法是先
git remote set-branches origin '*'确保 fetch 规则干净，再git fetch --prune origin（--prune 是关键，它会主动删掉本地已不存在于远程的 tracking ref） - 若仍慢，临时禁用 reflog：
git config --local core.logAllRefUpdates false，避免每次 fetch 都写 reflog（尤其在 CI 环境） - 检查
.git/config中是否有大量重复的[remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/*行——手动编辑配置文件删冗余行，Git 不会自动去重
git worktree list 显示一堆已失效路径，导致 git status 也变慢
git worktree 的元数据存在 .git/worktrees/ 下，每个子目录对应一个工作树。但如果你用 rm -rf 直接删了工作树目录，Git 不知道它没了，仍会在 worktrees/ 里留着记录。每次运行 git status 或 git branch，Git 都会尝试读取这些路径下的 .git 文件校验有效性——路径不存在就报错、重试、超时，叠加起来就是秒级延迟。
- 先运行
git worktree repair（Git 2.35+），它能自动检测并清理失效条目 - 老版本 Git（ls .git/worktrees/ 查出疑似失效目录，用
stat .git/worktrees/xxx/gitdir看是否 No such file，确认后rm -rf .git/worktrees/xxx - 切勿直接删
.git/worktrees/整个目录：里面可能有正在用的工作树，且git worktree list输出的路径是相对路径，删错会导致其他工作树无法识别 - 日常习惯：删工作树务必用
git worktree remove /path/to/worktree，而不是rm -rf
为什么 git gc 不解决分支多的问题
git gc 管的是对象层（blob/tree/commit），不是引用层（refs）。万级分支残留的本质是磁盘上多了上万个 .git/refs/heads/xxx 文件和 .git/packed-refs 里的对应行——它们不占多少空间，但让 Git 的 ref 解析逻辑从 O(1) 退化成 O(N)。而 git gc 默认只打包松散对象、删悬空 commit，对 ref 文件完全无感。
-
git gc --aggressive也不会加速分支切换，它只影响objects/目录，不影响refs/目录的遍历效率 - 真正有效的“剪枝”动作只有三个：
git branch -d（删本地分支 ref）、git remote prune（删远程跟踪 ref）、git worktree remove（删工作树元数据） - 如果团队用 GitHub/GitLab，开启“自动删除已合并分支”设置，从源头减少 ref 生成，比事后清理重要十倍
分支树不是长在对象数据库里，是长在文件系统 ref 目录里；剪枝刀得对准那里，而不是对着 objects 目录狂砍。
