答案是大小写敏感导致本地分支名与远程分支名不匹配。git refspec匹配严格区分大小写，远程仓库（如github）也区分大小写，需用git ls-remote --heads origin确认真实分支名，再用git branch -m重命名本地分支并推送。
Git push 时提示 “src refspec xxx does not match any”
这是最典型的信号：你本地分支叫 feature/Login，但远程已有 feature/login（或反之），Git 默认不认为它们是同一个分支。Git 的 refspec 匹配是大小写敏感的，且大多数远程仓库（如 GitHub、GitLab）底层文件系统或 API 对分支名也区分大小写 —— 即使你在 macOS 或 Windows 上用大小写不敏感的文件系统操作，远程仍会严格区分。
先确认远程分支真实名称
别凭记忆或本地 git branch -r 输出判断，因为缓存可能滞后。直接查远程真实状态：
git ls-remote --heads origin | grep -i login
这条命令绕过本地引用，直连远程列出所有分支头，grep -i 能帮你发现大小写变体。你会看到类似：
abcd123... refs/heads/feature/login
说明远程实际存在的是小写的 feature/login，而你本地是 feature/Login —— 这就是冲突根源。
使用 gh project CLI 管理 GitHub Projects v2。在代理需要列出待办事项、设置项目字段（如状态、迭代、优先级等）时使用此技能。
安全重命名本地分支并推送
不要强行 git push origin :feature/Login 删除（可能误删远程分支），也不要直接 git checkout -b 新建同名分支再 push（会多出一个分支）。正确做法是重命名本地分支，再显式推送：
- 重命名本地分支：
git branch -m feature/Login feature/login - 将本地
feature/login推送到远程同名分支：git push origin feature/login - 如果远程已有
feature/login，Git 会拒绝覆盖（除非加-f）。此时应先git pull origin feature/login合并或确认无冲突，再 push
注意：重命名后，原分支引用消失，所有基于它的未提交变更仍在当前工作区，不影响代码。
Windows/macOS 用户特别容易踩的坑
本地文件系统不区分大小写，导致你能同时创建 feature/Login 和 feature/login 分支（其实后者会覆盖前者），但 Git 内部引用已混乱。一旦推送到远程，问题暴露：
-
git branch -a可能显示两个分支，但git show-ref会揭示它们指向同一 commit 或出现 dangling ref - 执行
git checkout feature/Login有时静默切到feature/login，你以为在操作 A，实际在改 B - CI/CD 流程（如 GitHub Actions）运行在 Linux 上，大小写敏感，会直接失败
遇到这类情况，优先用 git show-ref --heads 查看真实 ref 列表，再清理冗余分支：git branch -d feature/Login（如果它只是 dangling 引用）。
