git ls-remote --heads origin 是唯一能实时验证远程分支存在的命令，它绕过本地缓存直连服务器查询 refs/heads/，输出如 a1b2c3d refs/heads/main，需用 awk '{print $2}' | sed 's/refs\/heads\///' 提取分支名，不创建跟踪分支、不触发 fetch，适合 ci 或排查同步问题。

git ls-remote --refs origin 显示所有远程分支名

直接看远程仓库当前有哪些分支，最轻量、最可靠的方式就是绕过本地 Git 索引，用 git ls-remote 查服务端快照。它不依赖本地 refs/remotes/origin/ 是否陈旧，也不触发 fetch，适合 CI 脚本或快速探查。

常见错误是误用 git branch -r——它只显示你本地已记录的远程分支（即上次 git fetch 后缓存的结果），一旦别人新推了 feature/v2，你没 fetch 过就看不到。

• git ls-remote --refs origin 输出形如 abc123 refs/heads/main，需自己提取 refs/heads/ 后的部分
• 加 --sort=-v:refname 可按字母倒序排，方便找最新命名的分支
• 如果远程用了非默认 refspec（比如只同步 refs/heads/release/*），要加 refs/heads/* 显式限定范围

git fetch --prune origin 同步并清理过期分支

想让本地 git branch -r 结果跟远程实时一致，必须先同步元数据。git fetch origin 默认不会删掉已被远程删除的分支引用，久而久之 origin/old-deprecated 会一直残留。

关键在 --prune：它会在 fetch 完后自动删掉本地已不存在对应远程分支的 refs/remotes/origin/xxx 引用。

• 执行后立刻可用 git branch -r 查看干净列表
• 等价配置：设 git config --global remote.origin.prune true，之后每次 git fetch origin 都自动 prune
• 注意：prune 不影响本地分支（git branch 列出的），只清理 origin/xxx 这类远程跟踪引用

git ls-remote origin 'refs/heads/*' 过滤纯分支，排除 tag 和其他 ref

默认 git ls-remote origin 会混着输出 refs/tags/v1.0、refs/pull/123/head 等，干扰分支识别。明确限定路径模式能一步到位。

Git Hub Projects V2

使用 gh project CLI 管理 GitHub Projects v2。在代理需要列出待办事项、设置项目字段（如状态、迭代、优先级等）时使用此技能。

下载

单引号包裹 'refs/heads/*' 是为了防止 shell 展开通配符，确保交给 Git 处理。

• 输出每行是 commit-hash refs/heads/branch-name，用 cut -d/ -f4- 或 sed 's|refs/heads/||' 提取分支名
• 某些托管平台（如 GitLab）支持 refs/heads/** 匹配嵌套分支（如 feature/login/ui），但 GitHub 不支持，得用 refs/heads/* + 后续过滤
• 若远程禁用了匿名访问，该命令会失败；此时必须先 git fetch 再查 git branch -r

为什么 git branch -a 不适合查“最新”分支

git branch -a 罗列本地所有分支 + 所有远程跟踪分支，但它完全不刷新远程状态。它的“远程分支”部分 = 上次 fetch 时存下的快照，可能几天前就过期了。

尤其在团队高频推送分支的场景下，有人刚推了 hotfix/db-timeout，你运行 git branch -a | grep hotfix 却返回空——不是没有，是你本地还没同步元数据。

• 它适合快速浏览“我当前知道哪些分支”，不适合做自动化判断或依赖分支是否存在
• 和 git branch -r 行为一致，只是多加了本地分支；两者都受 fetch 滞后性影响
• CI 流水线里若用它做分支存在性检查，大概率出错，应改用 git ls-remote 或先 git fetch --prune

真正要注意的是：远程分支列表不是静态事实，而是服务端某一时刻的状态快照。无论用哪种方法，都要意识到它可能在你拿到结果的下一秒就被删掉或重命名——别把它当数据库一样长期缓存。