Git分支重命名本质是移动指向commit的指针，不改变工作区、暂存区或任何文件状态；执行后git status显示“clean”属正常，因该操作仅更新.git/refs/heads/下分支文件内容。
重命名分支不会改变任何文件状态
Git 分支重命名 git branch -m 本质是移动一个指向 commit 的指针，不触碰工作区、暂存区或任何 tracked/untracked 文件。执行后 git status 显示 “nothing to commit, working directory clean” 是正常现象——不是“没生效”，而是它本来就不该动文件。
常见误解是以为重命名会刷新 IDE 缓存、更新 .gitignore 规则或触发 hooks，其实都不会。你编辑过的文件仍处于已修改状态，未跟踪的文件仍显示为 untracked，所有 staged 内容也原样保留。
当前在待重命名分支上时，必须用单参数 git branch -m
如果你正处在 feature/login 分支上，直接运行 git branch -m feature/auth 即可。Git 会自动识别当前分支并重命名它。
若此时错误地写成双参数形式（如 git branch -m feature/login feature/auth），Git 会报错：fatal: Branch rename failed —— 因为它试图把一个正在检出的分支当成普通分支来操作，而这是被禁止的。
- 不在该分支时，才必须写全两个参数：
git branch -m old-name new-name - 输错旧名（比如拼错），Git 不报错，而是新建一个叫
new-name的分支，原分支完好无损 - 新名含点号、斜杠等字符（如
hotfix.1.2），必须加引号：git branch -m "hotfix.1.2" "fix/1.2"
远程分支重命名后，本地需手动重建上游追踪
远端分支被重命名（例如 GitHub 上把 test_dev 改成 test_new_dev）后，本地 git branch -v 仍显示它跟踪 origin/test_dev，但这个引用已不存在。此时 git pull 或 git push 会失败，并提示 upstream is gone。
正确做法不是删掉本地分支再重新拉取，而是复位追踪关系：
- 先
git fetch origin获取远端最新分支列表 - 用
git branch --set-upstream-to=origin/test_new_dev test_new_dev手动绑定 - 验证：
git branch -vv应显示[origin/test_new_dev]
漏掉这步，后续所有无参数的 git push 和 git pull 都会继续尝试操作已删除的远程分支，CI 流水线也可能持续监听旧名触发构建。
IDE 和 Git GUI 工具常缓存旧分支名
VS Code、IntelliJ、GitKraken 等工具通常不会实时监听 .git/refs/heads/ 文件变化，分支重命名后界面可能仍显示旧名，甚至提交时默认推送到旧远程路径。
这不是 Git 本身的问题，而是工具层缓存导致的：
- VS Code：关闭并重启窗口，或点击底部状态栏分支名 → “Refresh all branches”
- IntelliJ：VCS → Git → “Branches…” → 右键旧分支 → “Delete Branch…”（仅删本地缓存），再右键远程分支 → “Checkout as new branch”
- GitKraken：菜单栏 Repository → Refresh remote branches
最稳妥的方式是重命名后立刻在终端执行一次 git branch -a 和 git branch -vv，以终端输出为准——工具界面只是视图，Git 状态只存在于 .git 目录里。
