git config --global --show-origin --list 是最可靠方式，直接显示全局配置来源路径，优先检查 ~/.gitconfig 和 ~/.config/git/config，前者存在则后者被忽略，Windows 对应 C:\Users\<用户名>\.gitconfig。
用 git config --global --show-origin --list 直接问 Git 自己
这是最可靠的方式，不依赖经验、不猜路径、不看文档。Git 本身知道它读的是哪个文件，--show-origin 就是让它把来源路径打出来。
执行后你会看到类似这样的输出：
file:/Users/alex/.gitconfig user.name=Alex Chen file:/Users/alex/.gitconfig user.email=alex@example.com file:/Users/alex/.gitconfig core.editor=code --wait
第一列的 file:/Users/alex/.gitconfig 就是真实路径。注意：如果显示的是 file:/Users/alex/.config/git/config，说明你或某个工具（比如某些 IDE 或包管理器）启用了 XDG 基目录规范，Git 会优先读这个位置而非 ~/.gitconfig。
- 该命令只查全局配置；加
--system查系统级，加--local（在仓库内运行）查本地级 - 若输出为空，说明当前没设任何全局配置，
.gitconfig文件可能尚未生成 - 不同 Git 版本对
--show-origin的支持程度略有差异，2.20+ 基本都支持
检查两个常见路径：~/.gitconfig 和 ~/.config/git/config
Mac/Linux 上 Git 全局配置文件就在这两个地方之一，不会出现在别处。前者是传统路径，后者是较新规范下的路径。两者互斥——Git 启动时只读其中一个，优先级是：~/.gitconfig > ~/.config/git/config（即如果前者存在，后者会被忽略）。
你可以手动验证：
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
-
ls -la ~/.gitconfig—— 看是否存在且可读 -
ls -la ~/.config/git/config—— 注意~/.config/git/目录本身可能不存在，需逐级检查 - 如果两个都不存在，运行一次
git config --global user.name "test"，Git 会自动创建~/.gitconfig
Windows 用户对应检查：C:\Users\<用户名>\.gitconfig，注意部分 Git 安装（如通过 Scoop 或 WSL）可能走 XDG 路径，但概率较低。
为什么 git config --list 有时不显示路径？
因为默认不带 --show-origin，它只输出键值对，比如：
[user] name = Alex Chen email = alex@example.com
你无法判断这些配置是从哪来的——尤其当系统级和全局级有同名配置、或某条配置被仓库级覆盖时，容易误判生效位置。
-
git config --list是“结果导向”，适合快速核对值是否正确 -
git config --list --show-origin是“溯源导向”，适合排查冲突、调试生效逻辑 - 如果在仓库中运行
git config --list --show-origin，你会看到三行来源：system、global、local，顺序即优先级
配置未生效？先确认你改的是哪个层级的文件
新手常犯的错误是：在 ~/.gitconfig 里改了 user.name，但进到某个仓库后运行 git config user.name 却返回空，或者返回旧值。这是因为该仓库的 .git/config 中显式设置了 [user] name = …，覆盖了全局配置。
- 查当前仓库生效的用户名：
git config user.name（不带--global） - 查它来自哪：
git config --show-origin user.name - 删掉仓库级配置（如果不需要）：
git config --unset user.name - 修改后记得用
git config --get user.name验证，而不是只看文件内容
真正复杂的地方不在路径本身，而在于「哪一层的配置正在起作用」——--show-origin 是唯一能立刻厘清这件事的手段，其他方式全是间接推断。
