一台电脑，多个 Git 身份：用 .gitconfig 按目录自动切换提交用户名

如果你和我一样，一台电脑上同时放着个人项目、公司项目、外包项目，迟早会遇到一个很烦的问题：代码都写完了，提交时却发现 Git 作者信息不对。

最常见的情况是：

• 个人仓库用了公司的邮箱提交。
• 公司仓库里出现了私人昵称和私人邮箱。
• 明明代码推到了 GitHub，但贡献记录没有正确归属到对应账号。
• 每次切项目都要手动改一次 git config user.name 和 git config user.email，麻烦，而且很容易忘。

这篇文章写的就是怎么把这件事一次性配好。

先说清楚一个容易混淆的点：这里说的“用户名”，严格讲不是 GitHub 或 GitLab 的登录账号，而是 Git 提交记录里的 user.name 和 user.email。.gitconfig 解决的是“这次提交显示谁、显示什么邮箱”，不是“你用哪个账号推送代码”。

为什么这件事值得专门配置

如果整台电脑只维护一种 Git 身份，那全局配置一次就够了：

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

问题是，真实开发环境通常不是这样。

你可能会同时面对三种仓库：

• 自己的个人项目，希望保留自己的名字和私人邮箱。
• 公司的项目，需要使用公司规范里的姓名和公司邮箱。
• 客户或合作项目，可能又要单独用另一套身份。

这时候如果还只靠一份全局 Git 身份，就会开始出现各种边界问题：

• 提交记录混乱，回头看日志时一眼分不清哪部分属于哪个公司或哪类项目。
• 私人邮箱可能被公开暴露在不该出现的仓库里。
• GitHub 贡献统计可能归不到你想要的账号上。
• 新 clone 一个仓库后，第一件事总要先检查身份有没有配错。

本质上，这不是“不会配 Git”，而是项目身份已经分层了，但 Git 还停留在“整台电脑只有一个人”的配置方式里。

这套做法到底解决了哪些痛点

我后来固定用 .gitconfig 按目录切身份，主要就是因为它把下面几件事同时解决了：

• 不用再每进一个项目就手动切一次 user.name 和 user.email。
• 新仓库只要 clone 到指定目录下，就会自动继承正确身份。
• 个人项目和工作项目之间不会互相串作者信息。
• 提交前不用反复担心“这次是不是又用了错误邮箱”。
• 目录结构一旦稳定下来，后续几乎不用再维护。

更直接一点说，这不是为了炫配置，而是为了减少低级失误。

核心思路其实很简单

思路就是把 Git 配置拆成两层：

• 主配置文件 ~/.gitconfig 负责判断“当前仓库属于哪个目录”。
• 不同身份分别放在独立配置文件里，比如 ~/.gitconfig-personal、~/.gitconfig-work。

然后通过 includeIf 告诉 Git：

• 如果仓库在个人项目目录里，就读个人身份配置。
• 如果仓库在公司项目目录里，就读公司身份配置。
• 如果仓库在客户项目目录里，就读客户身份配置。

这样 Git 在进入不同仓库时，就会自动选对那套身份。

我现在用的配置方式

假设我的本地目录是这样分的：

~/CodeWork/personal/
~/CodeWork/work/
~/CodeWork/client/

那么我的主配置文件 ~/.gitconfig 可以这样写：

[user]
    useConfigOnly = true

[includeIf "gitdir:~/CodeWork/personal/"]
    path = ~/.gitconfig-personal

[includeIf "gitdir:~/CodeWork/work/"]
    path = ~/.gitconfig-work

[includeIf "gitdir:~/CodeWork/client/"]
    path = ~/.gitconfig-client

这里我建议把 user.useConfigOnly = true 一起打开。

它的作用是：如果当前仓库没有匹配到任何一套身份配置，Git 就不要偷偷使用一个错误的默认身份，而是直接提醒我“你还没配”。对多身份场景来说，这比静默出错稳得多。

然后分别创建几份独立配置文件。

个人项目配置 ~/.gitconfig-personal：

[user]
    name = 你的个人名字
    email = [email protected]

公司项目配置 ~/.gitconfig-work：

[user]
    name = 你的公司提交名
    email = [email protected]

客户项目配置 ~/.gitconfig-client：

[user]
    name = 你的客户项目身份名
    email = [email protected]

如果你更习惯直接看文件层级，那其实最清楚的写法就是把 ~ 目录下会出现的几个文件直接列出来。

先看目录结构：

~
├── .gitconfig
├── .gitconfig-personal
├── .gitconfig-work
├── .gitconfig-client
└── CodeWork
    ├── personal
    │   └── my-blog
    ├── work
    │   └── company-admin
    └── client
        └── brand-site

这个结构里，关键点只有两个：

• ~ 下面放的是 Git 配置文件本身。
• ~/CodeWork/ 下面按项目类型分目录，Git 就靠这个目录结构去判断该加载哪一份身份配置。

1. ~/.gitconfig

这是总入口，只负责“分流”，不直接写个人姓名和邮箱。

[user]
    useConfigOnly = true
    # 如果没有命中任何身份配置，就直接报错
    # 避免 Git 偷偷使用一个错误的默认身份

[includeIf "gitdir:~/CodeWork/personal/"]
    path = ~/.gitconfig-personal
    # 只要仓库位于 ~/CodeWork/personal/ 下
    # 就加载个人身份配置

[includeIf "gitdir:~/CodeWork/work/"]
    path = ~/.gitconfig-work
    # 只要仓库位于 ~/CodeWork/work/ 下
    # 就加载公司身份配置

[includeIf "gitdir:~/CodeWork/client/"]
    path = ~/.gitconfig-client
    # 只要仓库位于 ~/CodeWork/client/ 下
    # 就加载客户项目身份配置

2. ~/.gitconfig-personal

这个文件只放个人项目要使用的提交身份。

[user]
    name = 你的个人名字
    email = [email protected]
    # 这套身份会用于 ~/CodeWork/personal/ 下的仓库

3. ~/.gitconfig-work

这个文件只放公司项目的提交身份。

[user]
    name = 你的公司提交名
    email = [email protected]
    # 这套身份会用于 ~/CodeWork/work/ 下的仓库

4. ~/.gitconfig-client

如果你还需要给客户或合作项目单独保留一套身份，就单独拆这一份。

[user]
    name = 你的客户项目身份名
    email = [email protected]
    # 这套身份会用于 ~/CodeWork/client/ 下的仓库

5. 这套目录为什么能自动生效

你把仓库放到不同目录下以后，Git 的判断逻辑其实就是下面这样：

~/CodeWork/personal/my-blog/.git      -> 读取 ~/.gitconfig-personal
~/CodeWork/work/company-admin/.git    -> 读取 ~/.gitconfig-work
~/CodeWork/client/brand-site/.git     -> 读取 ~/.gitconfig-client

所以这套方案真正依赖的，不是“你记得切身份”，而是“你本地目录结构本身是稳定的”。

如果你只有两种身份，其实保留两份就够了，不需要为了“看起来完整”硬拆出很多文件。

怎么验证它有没有真的生效

配完之后，不要直接相信自己写对了，最好进入不同目录下的仓库分别检查一次。

比如进入一个个人项目仓库后，执行：

git config user.name
git config user.email

如果想进一步确认这些值是从哪份配置文件读出来的，可以执行：

git config --show-origin --get user.name
git config --show-origin --get user.email

它会直接告诉你当前生效的是哪一个文件。

这个检查动作我很建议保留，因为它能非常快地确认：

• 目录有没有匹配对。
• 配置文件路径有没有写错。
• 当前仓库到底继承的是哪套身份。

这套方案最容易踩的几个坑

真正容易出问题的，通常不是思路，而是细节。

第一，不要把“提交身份”和“推送账号”混为一谈。

.gitconfig 只决定 commit 里记录的作者信息，不决定你 push 时用哪个平台账号登录。如果你一台电脑上还要同时登录多个 GitHub 或 GitLab 账号，那通常还要继续配 SSH config、不同的 SSH key，或者使用对应的凭证管理器。

第二，目录规则要从一开始就分清楚。

这套方案成立的前提，就是你本地仓库真的按类型分开放。如果你的个人项目和公司项目全都混在一个总目录里，includeIf "gitdir:..." 就没有办法稳定判断。

第三，配完以后一定要做一次实际验证。

最稳的方法不是“看起来没问题”，而是在不同目录里各找一个仓库，跑一遍：

git config --show-origin --get user.email

看到来源文件正确，才算真的配好。

第四，如果你已经提交错了身份，越早修越省事。

如果错误提交还没 push，可以直接修：

git commit --amend --reset-author

如果已经 push 到远端，再去改历史就会开始影响协作，这时候就不能只当成一个本地小问题来处理了。

我为什么最后固定用了这套方式

因为它最符合真实开发习惯。

我不想在每个仓库里单独写一遍身份配置，也不想每次切项目先想一遍“我现在应该是谁”。我更希望目录结构一旦定好，这件事就自动发生。

.gitconfig + includeIf + gitdir 这套组合的价值就在这里：

• 它不是在每个仓库里打补丁。
• 它是把身份切换这件事，前置到目录规划这一层。
• 目录一旦稳定，后续新项目基本零额外成本。

这也是为什么我会建议，只要你一台电脑上已经不止一种 Git 身份，就尽快把它配起来。越晚配，越容易在某一次顺手提交里留下错误记录。

一句话总结

如果你的个人项目、工作项目、客户项目本来就放在不同目录下，那么最省心的做法，就是让 ~/.gitconfig 按目录自动加载不同身份配置。

这样你解决的不是一个“Git 小技巧”，而是一类长期反复出现的低级错误。