Git分支混乱源于本地分支、远程跟踪关系与提交历史脱节；需先用git branch -vv查状态、git remote prune origin清理失效引用、git branch --merged确认已合并分支，再安全删除。
分支混乱不是 Git 本身出错，而是本地分支状态、远程跟踪关系、提交历史三者脱节导致的。直接删分支或硬重置往往让问题更糟——你得先看清「谁在跟踪谁」「哪些提交还活着」「哪些分支其实已合并」。
怎么看当前分支和远程跟踪关系是否错位
很多人以为 git branch -a 列出来的分支名都“有效”，其实很多是过期的远程分支引用（比如 origin/feature/login-old），或者本地分支早已被远程删除但没清理。Visual Studio 不会自动 prune 这些。
- 在 Visual Studio 中打开
Git 存储库窗口（Ctrl+0,R），左侧选Branches / Tags - 右键任意带
origin/前缀的分支 → 如果菜单里没有Delete remote branch，说明它可能已不存在于远程，只是本地缓存残留 - 右键本地分支 → 查看
Configure Remote Tracking是否指向正确的远程分支（比如feature/new-api应该跟踪origin/feature/new-api，而不是origin/main） - 终端执行
git remote prune origin可批量清理失效的origin/*引用（VS 不提供此操作入口）
怎么安全地清理已合并但残留的本地分支
误删未合并分支会导致提交丢失；但留着一堆 merged-into-main 的分支，又会让 Git 存储库 窗口变得难以导航。关键是区分「真合并」和「假合并」——后者指分支被 merge 过但没 push，或只 rebase 过没真正集成。
- 在 VS 中右键本地分支 → 若菜单中出现
Merge into current branch且灰显，大概率已合并；若可点，说明还没合并 - 更可靠的方式：终端执行
git branch --merged main（把main换成你的目标基线分支），列出所有可安全删除的本地分支 - 删除前务必确认：这些分支的 HEAD 提交是否出现在
main的历史中（git log --oneline main | grep <commit-hash>） - VS 中删除分支后，记得手动执行
git fetch --prune，否则下次打开Git 存储库窗口还会显示旧的远程分支
rebase 后分支指针错乱怎么办
用 VS 的 Squash Commits 或右键 Rebase onto... 后，有时发现原分支还在，新提交却堆在另一个分支上，甚至出现重复提交 ID。这是因为 rebase 创建了新提交对象，而原分支引用没动，也没自动切换 HEAD。
- rebase 完成后，VS 通常不会自动切换到目标分支 —— 你得手动点击右下角分支名，选回目标分支（如
main） - 如果原功能分支（如
feature/x）已无用，别急着删；先git checkout feature/x && git reset --hard origin/feature/x恢复它到远端状态，再决定是否删 - VS 的
Rebase onto...不支持交互式编辑（比如改 pick 为 drop），复杂重写必须用命令行：git rebase -i HEAD~5 - 一旦 rebase 出现冲突，VS 的合并编辑器能用，但解决后必须在终端运行
git rebase --continue，仅点 VS 的Accept Merge不会推进 rebase 流程
最常被忽略的一点：Visual Studio 的分支操作依赖 Git 配置中的 pull.rebase 和 push.default。如果它们设成 merge 或 upstream，而你习惯用 rebase 工作流，分支图就会越来越歪。检查方式：git config --get pull.rebase 和 git config --get push.default —— 建议团队统一设为 true 和 current。
