核心原因是core.quotepath默认为true导致git将远程分支名中非ascii字节转义为八进制序列（如\345\271\277），执行git config --global core.quotepath false即可关闭转义，使分支名原样显示，同时需确保终端编码为utf-8。
远程分支名在本地 git branch -r 或 git ls-remote 中显示为乱码（如 origin/feature\345\271\277\345\221\20A），不是 Git 服务端问题，而是本地 Git 解析远程引用时路径转义 + 终端解码不匹配导致的。核心只需关掉转义、对齐编码、避免混用环境。
git branch -r 显示八进制转义（如 \345\271\277）
这是 core.quotepath 在作祟——Git 默认把远程分支名里所有非 ASCII 字节（包括中文）强制转成 C 风格八进制序列，纯属显示层压制，不影响实际引用。
- 执行
git config --global core.quotepath false即可关闭转义，让分支名原样输出 - 若只对当前仓库生效，去掉
--global，运行git config core.quotepath false - 检查是否被项目级配置覆盖：
git config --local core.quotepath，优先级高于全局 - 注意：该设置不改变 Git 内部存储或传输行为，仅影响
git branch、git ls-remote等命令的终端输出
git ls-remote origin 显示 ? 或方块，但 branch -r 正常
说明 Git 已正确解析远程引用，但分页器或终端无法渲染 UTF-8 字节流。常见于 Windows CMD 或未配 LESSCHARSET 的 Git Bash。
- Windows CMD：必须先执行
chcp 65001切到 UTF-8，再运行git ls-remote - Git Bash / macOS Terminal：确保
export LESSCHARSET=utf-8已写入~/.bashrc或~/.zshrc，并重载（source ~/.bashrc） - PowerShell：需设
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8，否则git ls-remote输出会被截断或错位 - 验证终端是否就绪：
echo "中文" | cat能正常显示，才说明终端层已通
远程分支名本身含乱码（如 origin/featu?branch）
这不是显示问题，是分支创建时编码错误已固化在远程仓库中。典型场景：有人用 GBK 终端提交了中文分支名，Git 把 GBK 字节当 UTF-8 存进了 ref，服务端（GitHub/Gitee）照存不误。
- 无法通过本地配置修复——乱码已写入远程
refs/remotes/origin/xxx - 安全做法：让创建者用正确编码重命名分支：
git push origin :旧分支名 新分支名 - 本地可临时映射：在
.git/config的[remote "origin"]下加fetch = +refs/heads/旧分支名:refs/remotes/origin/新分支名 - 预防措施：全员执行
git config --global i18n.commitencoding utf-8，并禁用 GBK 环境
真正棘手的是「远程分支名乱码」和「本地显示乱码」混在一起——比如 git branch -r 显示 origin/feature\345\271\277，而服务端网页却显示 origin/featu?branch。这时得先确认乱码源头在哪一层：是 Git 解析错了，还是分支名本来就是错的。别急着改配置，先用 git ls-remote --refs origin | iconv -f gbk -t utf-8 2>/dev/null 试探性解码，再决定动哪一环。
