升级 Git 版本本身不会改变文件存储编码，中文乱码通常是终端显示配置或 Git 路径转义策略导致的。在 Git 2.x 版本中，最核心的修复方式是调整 core.quotepath 配置，无需过多关注已废弃的 i18n 编码设置。

命令速用版

如果希望快速修复，可在终端依次执行以下命令，设置全局配置：

git config `--global` core.quotepath false

对于 Windows Git Bash 用户，若 git log 仍显示乱码，需设置分页器环境变量：

export LESSCHARSET=utf-8

建议将 LESSCHARSET 设置写入 ~/.bashrc 中，以便永久生效。CMD 或 PowerShell 用户通常只需执行第一条 git config 命令即可。

为什么会这样

Git 在设计之初主要面向英文环境，其核心配置 core.quotepath 默认值为 true。当 Git 输出文件路径时（例如在 git status 或 git diff 命令中），如果检测到字符的字节值大于 0x80（即非 ASCII 字符，包括中文），它会认为这些字符“不寻常”。

为了确保路径在任何终端环境下都能被无歧义地输出，Git 会将这些字符转换为八进制转义序列（例如\345\271\277）。这原本是一种安全机制，防止因终端编码不支持而导致路径解析错误，但在中文环境下会造成显示乱码。升级 Git 版本后，如果配置文件被重置或终端环境变化，这一问题往往会重新显现。

注意：Git 2.x 版本已默认采用 UTF-8 处理提交信息，因此旧教程中的 i18n.commitencoding 等配置通常不再需要，过度配置反而可能引起混淆。

分步处理

按照以下步骤逐步配置，确保从文件路径到提交信息都能正常显示：

1. 关闭路径转义

执行以下命令，告诉 Git 不要对高字节字符进行转义：

git config `--global` core.quotepath false

此设置仅影响 git status、git diff `--name-only` 等带路径输出的命令，不影响提交、克隆等核心操作。

2. 调整终端环境变量（仅 Git Bash 用户）

在 Windows Git Bash 中，有时需要显式指定 less 分页器的编码。编辑 ~/.bashrc 文件，添加以下内容：

export LESSCHARSET=utf-8

保存后重启终端，或执行 source ~/.bashrc 使其生效。CMD 用户无需此步骤，若遇乱码请检查控制台字体设置。

怎么验证是否生效

配置完成后，通过以下方法验证修复效果：

1. 检查文件状态

创建一个包含中文文件名的文件，执行：

git status

如果文件名显示为正常的汉字，而不是\xxx 形式的转义序列，说明 core.quotepath 配置生效。

2. 检查提交日志

执行：

git log

观察提交信息中的中文是否正常显示，无乱码或问号。

3. 检查配置列表

执行以下命令确认配置已写入：

git config `--global` `--list` | grep -E "(encoding|quotepath)"

常见坑

在配置过程中，以下几个场景容易导致问题反复：

1. 项目级配置覆盖

如果已设置全局配置但仍无效，检查当前项目目录下是否有局部配置覆盖。执行 git config `--local` core.quotepath 查看，如有必要可删除局部配置或强制指定。

2. 历史提交编码不一致

如果团队中有人曾用 GBK 编码提交过代码，即使你设置了 UTF-8，拉取后仍可能显示乱码。这种情况下需从源头统一编码规范，Git 2.x 无法自动转换历史提交编码。

3. 终端字体不支持

在 Windows 控制台，如果字体不支持 Unicode，即使配置正确也可能显示方块。建议在 Git Bash 选项中选择 Consolas 或 Sarasa Mono 等支持中文的 TrueType 字体。