根本原因是core.quotepath默认为true，git将中文等非ascii字符转义为八进制序列；解决只需执行git config --global core.quotepath false，并确保终端编码为utf-8（如windows需chcp 65001），git log乱码则需同步配置i18n.commitencoding、i18n.logoutputencoding及lesscharset。
git status 显示中文文件名为八进制转义（如 \344\270\255\346\226\207）
这是 core.quotepath 默认为 true 导致的——Git 把所有非 ASCII 字符（包括中文）强制转成 C 风格的八进制序列，纯属显示层压制，不改存储。
解决只需一条命令：
-
git config --global core.quotepath false（全局生效） - 或仅当前仓库：
git config core.quotepath false
但注意：设完后仍乱码，大概率是终端没跟上。Windows CMD 必须先执行 chcp 65001 切到 UTF-8；Git Bash / Windows Terminal 默认 OK；macOS/Linux 终端一般无需操作，但建议检查 locale | grep UTF-8 确认输出含 UTF-8。
git log 提交信息或作者名显示为 或方块
这和 core.quotepath 无关，是 Git 读取/输出 commit message 时的编码链断了。关键在三处配置是否对齐：
-
git config --global i18n.commitencoding utf-8（告诉 Git：你存的 commit 是 UTF-8） -
git config --global i18n.logoutputencoding utf-8（告诉 Git：你输出 log 时也按 UTF-8 解码） -
export LESSCHARSET=utf-8（加到~/.bashrc或~/.zshrc，让分页器less正确渲染）
注意：i18n.logoutputencoding 在 Git ≥ 2.31 已标记为弃用，但 Windows 上仍建议保留；macOS/Linux 用户若设 utf-8 无效，可试 en_US.UTF-8。
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
Windows 下 git add 中文文件失败，报 “did not match any files”
这不是编码问题，而是 Git 实际没识别到文件路径——常见于旧版 Git（
必须检查并操作以下几点：
- 运行
git --version，确认 ≥ 2.31；否则升级 Git - 执行
git config --global core.protectNTFS false（仅 Windows，关闭 NTFS 保留名检查） - 避免混用 CMD 和 Git Bash 操作同一仓库：CMD 默认 GBK，Git Bash 默认 UTF-8，路径解析错位后 Git 根本找不到文件
- 极端情况可手动编辑
Git 安装目录/etc/gitconfig，追加两行：[core]outputEncoding = utf-8logOutputEncoding = utf-8
远程仓库看到中文文件名变成 %E6%97%A5%E5%B8%B8 这类 URL 编码
说明 Git 已把文件名实际存成了 URL 编码格式，不是显示问题，是底层路径处理失败。典型诱因：
- Git 版本太老（
- Windows 上未关
core.protectNTFS，NTFS 拦截后 Git 回退到安全但错误的编码方式 - 用 VS Code 内置终端提交、却用 CMD 查看状态，环境不一致导致 Git 缓存错乱
修复后务必验证：删掉本地 .git/index，再执行 git read-tree --reset -u HEAD 强制重载索引，否则旧编码残留会持续干扰。
最易被忽略的是终端本身——Git 配得再准，CMD 还卡在 GBK，git status 就永远是方块。别只调 Git，顺手敲 chcp 看当前代码页，再看终端字体是否支持 Unicode。
