Linux下Git配置文件层级详解
在Linux系统中管理多个Git身份，许多人误以为需要频繁“切换账号”。实际上，其核心机制是路径级的配置覆盖，而非全局登录态的切换。通过巧妙的配置文件加载顺序和条件包含规则，可以实现不同项目目录自动匹配对应的用户信息，从而有效避免Git提交记录（commit）出现作者信息混乱的问题。
Git多用户配置的本质：路径级覆盖，非“账号切换”
需要明确的是：Git本身并没有“当前登录用户”的概念。日常所说的多用户配置，实质上是让Git根据你正在操作的仓库所在位置，自动加载不同的user.name和user.email设置。若仅简单地在全局配置中固定一套信息，然后指望用命令行参数临时覆盖，不仅操作繁琐，而且极易出错，导致提交记录作者信息张冠李戴——这往往是开发者最常遇到的陷阱之一。
Git配置文件加载顺序：system → global → local，local优先级最高（完整解析）
Git读取配置遵循一个明确的链条，后加载的配置会覆盖先前的同名项。掌握这个顺序是配置管理的关键：
- 系统级（system）：对应系统级配置文件
/etc/gitconfig。这里的配置会影响机器上的所有用户，通常需要管理员权限才能修改，一般不建议轻易改动。 - 全局级（global）：对应当前用户主目录下的
~/.gitconfig或~/.config/git/config文件。使用git config --global命令修改的配置即保存在此。值得留意的是：这两个路径是互斥的，Git会优先查找~/.config/git/config，若不存在则回退到~/.gitconfig。最好不要同时配置两者，以免造成混淆。 - 仓库级（local）：对应每个Git仓库内的
.git/config文件。该配置仅对当前仓库生效，优先级最高。使用不带--global参数的git config命令就是修改这一层的设置。
利用includeIf实现“路径自动匹配用户”
如何优雅地让公司项目自动使用工作邮箱，个人项目自动使用私人邮箱？答案就是借助includeIf指令。你不再需要为每个仓库手动设置本地配置。
具体方法是在全局配置文件~/.gitconfig中添加条件包含规则：
# 编辑 ~/.gitconfig
[includeIf "gitdir:~/work/"]
path = ~/work/.gitconfig-work
[includeIf "gitdir:~/personal/"]
path = ~/personal/.gitconfig-personal
这段配置的含义是：当Git操作的仓库路径位于~/work/目录下时，自动引入~/work/.gitconfig-work文件；位于~/personal/目录下时，则引入~/personal/.gitconfig-personal文件。
接下来，分别创建这两个被引用的配置文件：
# ~/work/.gitconfig-work
[user]
name = Zhang San
email = zhangsan@company.com
# ~/personal/.gitconfig-personal
[user]
name = z.s.
email = zs@example.net
这样一来，当你进入~/work/project-a目录工作时，Git会自动加载工作配置；而切换到~/personal/blog目录时，则会无缝切换为个人配置。请注意，gitdir:后面的路径必须是绝对路径，且末尾的斜杠/可以确保匹配该目录下的所有子目录，但路径后不能有空格。
如何验证当前仓库实际生效的user配置
配置完成后，如何确认真的生效了？请不要仅依靠git config user.name这条命令的输出，因为它默认只显示全局（global）配置，可能掩盖了已被本地（local）配置覆盖的事实。
要查看当前仓库最终生效的所有用户配置项及其来源，可以使用以下命令：
git config --get-regexp 'user\.(name|email)'
它会列出所有找到的user.name和user.email设置，并清晰地标明每一项来自哪个配置文件（例如file:/home/yourname/.gitconfig或file:.git/config）。如果同一个配置项出现多次，那么列表中最靠后的那个就是实际生效的值。
最后，还有一个容易忽略的细节：某些集成开发环境（如VS Code）或图形化Git客户端可能会缓存配置信息。如果你修改了.gitconfig文件后发现没有立即生效，尝试重启这些工具，往往就能解决问题。
