必须先用git ls-remote --heads origin | grep -i s1或git show-ref --verify --hash refs/remotes/origin/feature/s1确认远程真实大小写，再重命名本地分支并执行git branch --set-upstream-to=origin/feature/s1，否则git push因push.default=simple强制校验大小写一致而持续失败。
Git远程分支名大小写不一致，不能靠改本地配置硬刚；必须先确认远程真实分支名，再同步本地分支名——否则 git push 会持续失败，git pull 却看似正常，这是最危险的假象。
怎么确认远程分支实际大小写？
别信本地 git branch -r 的输出，它可能缓存旧名或受 core.ignorecase 干扰。真正可靠的只有两个命令：
-
git ls-remote --heads origin | grep -i s1—— 直接查远程引用，大小写原样显示（注意：grep -i只用于筛选，输出里带大写S就是大写） -
git show-ref --verify --hash refs/remotes/origin/feature/S1—— 替换为你怀疑的大小写组合，返回哈希值才说明该远程引用真实存在
如果 git branch -r 显示 origin/feature/s1，但上面两个命令只返回 origin/feature/S1，那就坐实了：远程是大写，本地分支名错了。
本地分支名与远程不一致时，git push 为什么直接报错？
因为 Git 2.0+ 默认启用 push.default = simple，它强制要求：
- 本地分支已设置
upstream（即跟踪分支） - 本地分支名与
upstream分支名**逐字符完全相同**，包括大小写 - 一旦不匹配，
git push拒绝执行，防止误推到同名但不同源的分支
而 git pull 不校验大小写一致性，只要 upstream 配置存在，就尝试拉取——所以你常看到「pull 成功、push 失败」这种迷惑行为。
重命名本地分支并重设 upstream 的安全步骤
别用 git branch -m 一步到位，容易漏掉 upstream 关联。按顺序操作：
- 先确认当前分支没未提交改动：
git status -sb，有则先git stash或提交 - 重命名本地分支（假设远程是
feature/S1，本地是feature/s1）：git branch -m feature/s1 feature/S1 - 重设 tracking：
git branch --set-upstream-to=origin/feature/S1 - 验证：
git branch -vv应显示[origin/feature/S1]，且无警告
此时 git push 和 git pull 才真正对齐。跳过重设 upstream 这步，git push 仍会报 The upstream branch of your current branch does not match。
为什么不要全局执行 git config --global core.ignorecase false？
这个配置只影响**文件名**大小写识别（比如 User.php → user.php），对**分支名**完全无效。更关键的是：
- 在 Windows 上设为
false后，Git 会把大小写不同的文件当成两个独立文件处理，导致git checkout时提示 “untracked files” 冲突 - 协作中别人仍是
ignorecase = true，你推送的文件状态可能被对方忽略，引发静默不一致 - 分支名问题跟
core.ignorecase无关，强行改它既不解决问题，又埋下文件系统隐患
分支大小写问题永远只发生在分支命名和 tracking 配置层面——盯住 git branch -vv 和 git ls-remote，其它都是干扰项。
