先检查remote tracking分支是否还存在本地；报错“fatal: couldn't find remote ref refs/heads/old-name”说明远程已重命名分支（如dev→develop），而本地upstream配置仍指向旧名，需用git branch --set-upstream-to=origin/new-name更新追踪关系，并可选执行git remote prune origin清理过期引用。
git pull 无法找到远程分支时先检查 remote tracking 分支是否还存在
本地 git pull 报错 fatal: couldn't find remote ref refs/heads/old-name，说明 Git 仍试图拉取旧分支名，但远程已重命名（比如从 dev 改为 develop）。根本原因是本地的 upstream tracking 信息没更新——branch.old-name.merge 和 branch.old-name.remote 配置项仍指向旧名。
用 git branch --set-upstream-to 指向新远程分支
这是最直接的修复方式。假设远程新分支叫 develop，你当前在本地 dev 分支上：
git checkout dev git branch --set-upstream-to=origin/develop
之后 git pull 就会自动 fetch + merge origin/develop。注意：--set-upstream-to 只改 tracking 关系，不改本地分支名，也不影响提交历史。
- 如果本地分支也想同步改名（如把
dev改成develop），再执行git branch -m develop，然后重新设 upstream：git branch --set-upstream-to=origin/develop develop - 别用已废弃的
git branch --set-upstream（参数顺序易错，且不推荐） - 执行后可用
git config --get branch.dev.merge验证是否变成refs/heads/develop
删掉旧的 remote tracking 分支引用（可选但推荐）
远程分支重命名后，Git 不会自动清理本地缓存的 origin/old-name 引用。虽然不影响 pull，但 git branch -r 里仍显示它，容易混淆。
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
手动清理：
git remote prune origin
或更精准地删除单个引用：
git update-ref -d refs/remotes/origin/old-name
-
git remote prune origin会批量清理所有已不存在于远程的origin/*引用，安全且常用 - 别直接删
.git/refs/remotes/origin/old-name文件，可能破坏引用完整性 - 清理后
git fetch --prune才能保持远端引用状态最新
同步时要注意上游分支保护策略是否变化
远程分支重命名常伴随权限或保护规则调整（比如 develop 可能启用了强制 PR、线性提交或推送限制）。即使本地 tracking 设置正确，git push 仍可能被拒绝。
- 推送前先
git fetch origin，确认origin/develop的最新 commit ID - 检查是否有冲突：运行
git log HEAD..origin/develop --oneline看是否有 diverged 提交 - 若远程要求 fast-forward，而本地有额外提交，需
git rebase origin/develop或git merge origin/develop后再推 - 某些平台（如 GitHub/GitLab）会在 push 拒绝时返回具体策略提示，留意错误信息里的
remote: error:行
重命名分支本身不改变 commit ID，但 tracking 关系和远端引用状态必须手动对齐，漏掉任意一环都会导致后续操作异常。尤其当团队多人共用同一本地分支名时，务必同步沟通 rename 动作，避免有人还在往旧 upstream 推送。
