很多人早晚会撞上这个尴尬：上午还在公司仓库提交代码，下午打开自己的开源项目改几行，手一快就用自己的全局提交身份出去了。回头再看远程平台上的提交记录，要么公司邮箱出现在个人项目里，要么个人昵称混进公司仓库，两边都说不清。git 多账户配置要解决的就是这个场景——同一台电脑、多个代码托管账号、多套提交身份，彼此互不干扰。
这篇文章我把完整链路一次讲透：SSH 密钥怎么按账户隔离、~/.ssh/config里的 Host 别名机制怎么用、仓库级的user.name/user.email怎么配、新版 Git 的includeIf自动切换身份怎么搭，最后附上我在实际使用中踩过的坑和排查套路。适合电脑上同时存在公司项目和个人项目的开发者，也适合刚换新电脑、想把 Git 环境一次弄干净的人。这篇是系列里的第三篇，前两篇我跟大家聊过基础操作和分支策略，这篇直接上多账户这个硬骨头。
1. 为什么你的 Git 账户需要隔离
先说清楚一个问题：Git 的“账户”其实由三件事组成，很多人把这三件事混在一起，才导致配置一团乱。
第一是提交身份，也就是user.name和user.email。它写进每次 commit 的元数据里，是别人在平台上看到的“作者信息”。第二是认证通道。走 SSH 就是密钥对，走 HTTPS 就是用户名加令牌或密码。第三是远程仓库地址，也就是origin指向的位置，决定代码推到哪。
多账户配置的本质，就是让这三件事保持一一对应。公司项目用公司身份访问公司内网平台，个人项目用个人身份访问公共平台，谁也别污染谁。
1.1 一个账号打天下会翻哪些车
最常见的翻车现场是这样的：新电脑到手，图省事，先git config --global user.email "yourname@corp.com"，从此所有仓库都挂这个身份。个人开源仓库也是这个邮箱，推送到公共平台后，公司邮箱直接暴露在公开提交历史里，爬虫一扫就收集走了。
我自己见过更离谱的情况：同事用同一个 SSH 密钥同时绑定公司的内网平台和公共平台，某天内网平台做安全审计，管理员按公钥扫了一遍关联账号，个人项目也被翻出来了。另一个常见场景是离职换电脑，旧密钥没备份，新机器上所有仓库全部失效，还要逐个平台重新注册公钥，十分折腾。
还有一种反向操作也常见：几个人共用一个账号往同一仓库推代码。且不说提交记录分不清是谁写的，平台的风控模型很快会识别到异常，给你把账号冻结。我遇到过某团队共用账号被平台警告的事，最后还得走申诉流程，得不偿失。
1.2 多账户配置的核心思路与最小模型
多账户方案真正要记住的就三句话。
第一，每个账户独立生成一对 SSH 密钥。公钥加到对应平台的 SSH Keys 列表里，私钥留在本机。第二，在~/.ssh/config里给每个账户定义一个 Host 别名，让 SSH 知道访问“这个名字”时用哪把私钥。第三，在每个仓库内部单独设置user.name和user.email，不依赖全局配置。
我把这个过程想象成门禁卡。你住的小区有一张卡，公司大楼有一张卡，两把钥匙各不相同；你走到哪扇门前，就刷哪张卡。Git 的 Host 别名就是门上贴的标签，告诉你这张卡刷哪里。
这个模型一旦建立，后面加新账户、换新电脑都只是重复操作而已，不存在“牵一发动全身”的问题。
2. SSH 密钥与连接通道：从生成到连通
SSH 是 Git 最常用的认证通道。多账户配置的第一步，是让本机拥有多把互不影响的私钥。
2.1 一对一的密钥生成原则
生成密钥用ssh-keygen，一条命令搞定一对。
# 生成个人账户密钥 ssh-keygen -t ed25519 -C "personal-key" -f ~/.ssh/id_ed25519_personal # 生成公司账户密钥 ssh-keygen -t ed25519 -C "work-key" -f ~/.ssh/id_ed25519_work-t指定算法，ed25519是目前最推荐的选择，密钥短、生成快、安全性好，GitHub、GitLab 这些主流平台都支持。如果你的内网平台版本很古老，不认 ed25519，那就退回到rsa并明确 4096 位：
ssh-keygen -t rsa -b 4096 -C "work-key-rsa" -f ~/.ssh/id_rsa_work-C是注释，建议写清楚用途，方便以后用ssh-add -l查看时一眼认出来。-f指定私钥文件的保存路径。文件名建议带后缀区分账户，id_ed25519_personal和id_ed25519_work这种命名比默认的id_ed25519直观得多。
生成过程中会问要不要设置 passphrase。我的建议是：个人电脑、不涉及敏感项目，可以直接回车留空；如果电脑有外借可能，或者工作环境对安全要求高，就设置一个。设置了 passphrase 之后，每次使用私钥都要输入一遍，配合 ssh-agent 可以只输入一次，后面自动解锁。
生成完之后检查一下权限。Linux/macOS 下私钥文件权限不能太宽松：
chmod 600 ~/.ssh/id_ed25519_personal chmod 600 ~/.ssh/id_ed25519_work权限不对的话，SSH 会直接拒绝使用该私钥，报错里常带一句Permissions 0644 are too open。
2.2 ~/.ssh/config 的 Host 别名机制
本机有了多把私钥还不够，SSH 默认行为是：连接远程时按顺序尝试当前加载的所有私钥，直到服务器接受其中一把。这种行为在多账户场景下非常不靠谱，因为服务器看到第一把不认识的公钥就会拒绝，然后 SSH 才换下一把，浪费时间不说，错误信息也容易误导人。
解决办法就是在~/.ssh/config里显式声明“访问哪个地址用哪把私钥”。下面是一份可直接套用的配置：
# 个人账户 Host github-personal HostName github.com User git IdentityFile ~/.ssh/id_ed25519_personal IdentitiesOnly yes # 公司账户 Host gitlab-work HostName git.example.com User git IdentityFile ~/.ssh/id_ed25519_work IdentitiesOnly yes逐个解释关键项。
Host是你在本机给这个远程连接起的别名，只在本机有效，可以随便起，但它会成为仓库地址的一部分。比如：
git clone git@github-personal:yourname/demo.git这里的github-personal不是真实域名，而是 SSH 在 config 里匹配到的别名。匹配成功后，SSH 会自动去git.example.com的 22 端口连接，并使用指定的私钥。这个“名不副实”的地址设计非常巧妙，它让两台不同账户的仓库在本地看起来像来自不同服务器，实际指向同一个平台。
HostName是真实域名。公司自建平台就填内网域名，公开平台就填github.com。User固定为git，这是 Git 官方约定的用户名，不需要改成你的账号名。IdentityFile指向该账户对应的私钥文件，建议写~展开路径，不推荐用相对路径。IdentitiesOnly yes很关键，它让 SSH 只使用IdentityFile里指定的私钥，不去遍历 ssh-agent 里加载的其他密钥。少了这一行，即使你配置对了，agent 里如果还有旧的另一把同平台密钥，也可能先被送出去导致验证失败。
2.3 连通性验证与公钥注册
配置写好后，先把公钥内容复制到对应平台的 SSH Keys 设置页。
cat ~/.ssh/id_ed25519_personal.pub复制输出的一整行，粘贴到平台后端的 SSH Keys 里，保存。然后再验证连通性：
ssh -T git@github-personal ssh -T git@gitlab-work第一次连接会弹出 host key 确认提示，大意是问你认不认识这个远程指纹，输入 yes 回车即可。验证成功时，GitHub 类平台会返回一行类似Hi yourname! You've successfully authenticated的消息，GitLab 类平台返回Welcome to GitLab, @yourname!。看到这段话，说明密钥链已经通了。
我建议把这两条验证命令记在笔记里，每次改完配置都跑一遍，比直接去git clone试错快得多。
3. 提交身份隔离：仓库级配置与自动切换
SSH 通道解决的是“谁在连”，提交身份解决的是“记录里显示谁”。这两者在 Git 里是分开配置的。
3.1 三级配置优先级
Git 的配置有四个来源，按优先级从高到低分别是：命令行-c参数、仓库级 local、全局 global、系统 system。默认情况下，git config --global user.email一旦设置，所有仓库都会用这个邮箱，除非某个仓库的 local 配置里显式覆盖了它。
多账户场景最大的陷阱就在这里：大多数人装了 Git 之后会无意识执行一条git config --global user.name和git config --global user.email，然后所有仓库都被这一条身份绑架了。
我建议的兜底策略是：全局配置里只保留一些无害项，比如init.defaultBranch、pull.rebase之类的行为偏好；不要设置全局user.email。即使一定要设，也用一个不会造成误会的占位身份，避免手滑提交。真正的身份，交给每个仓库的 local 配置或includeIf去定。
查看当前生效的配置，用这个命令最直观：
git config --list --show-origin输出里每一行都会标注配置来自哪个文件，是全局的还是仓库自己的。排查“为什么身份还是不对”时，这条命令是第一利器。
3.2 仓库级 user 配置的正确用法
最简单的做法是克隆后立刻在仓库内配置。
git clone git@github-personal:yourname/demo.git cd demo git config user.name "你的昵称" git config user.email "personal@example.com"这样写入的是.git/config，只在这个仓库生效，不影响其他任何项目。这个仓库的所有后续提交都会带上这套身份，远程平台也会根据邮箱把提交关联到对应账号。
如果想在克隆前就指定身份，避免“克隆过程中产生的初始提交用了错误身份”这种问题，可以这样：
git -c user.name="你的昵称" -c user.email="personal@example.com" clone git@github-personal:yourname/demo.git-c是临时配置，优先级比 local 还高，只对这条命令及其子操作生效。敏感身份不落盘，用完即走，适合一次性操作。
这里提醒一个细节：平台判断提交人归属时，依据的是提交里的user.email。如果你的提交邮箱和平台账号邮箱不一致，提交记录会显示为一个独立作者，头像对不上，看起来就像是别人提交的。所以个人项目里用个人邮箱，公司项目里用公司邮箱，不只是“好看”，更是为了让提交记录能正确关联到人。
3.3 includeIf：按目录自动切换身份
手动在每个仓库里设置身份，配置安全，但麻烦。Git 2.13 之后提供了includeIf条件配置，可以做到“只要仓库落在某个目录下，就自动加载对应的身份配置”。我会优先推荐这个方案。
目录规划是第一位的。我的习惯是把个人项目和公司相关项目严格分层，比如：
~/work/ -> 公司相关项目 ~/personal/ -> 个人项目然后在全局配置里写条件加载：
# ~/.gitconfig [includeIf "gitdir:~/work/"] path = ~/.gitconfig-work [includeIf "gitdir:~/personal/"] path = ~/.gitconfig-personal [init] defaultBranch = main对应的子配置文件分别写身份信息。
~/.gitconfig-work：
[user] name = 职场用名 email = work@example.com~/.gitconfig-personal：
[user] name = 个人昵称 email = personal@example.com这样新建或克隆到~/work/下的仓库，自动套用工作身份；克隆到~/personal/下的仓库，自动套用个人身份。不需要在每个仓库里手动git config，也不会漏配。
三个容易踩的点先说清楚。
第一，gitdir:后面的路径结尾斜杠区别很大。gitdir:~/personal/表示“这个目录及其所有子目录里的仓库都匹配”，这是绝大多数人想要的效果。如果不带斜杠gitdir:~/personal，只匹配目录本身恰好是仓库根目录的情况，很容易让你误以为配置没生效。
第二，~必须能正确展开。如果你在includeIf里写了绝对路径但路径带空格，记得加引号，否则解析会出问题。
第三，多个includeIf同时匹配同一个仓库时，后面写的配置会覆盖前面写的同名配置。全局配置里保持目录条件互斥，是最省心的做法。别出现一个仓库既落在~/work/又落在~/personal/这种逻辑矛盾。
4. 实战中反复出现的坑与排查清单
配置步骤并不复杂，但实际使用中总有些问题让人挠头。我按真实频率整理了下面几个典型场景。
4.1 SSH 验证失败的典型路径
SSH 报Permission denied (publickey)时，我的排查顺序是固定的。
第一步，确认是不是真的走了 Host 别名。执行ssh -vT git@github-personal，看调试输出里读的是哪个IdentityFile。如果加载的私钥并不是你期望的那把，说明 config 的匹配有问题，检查 Host 拼写和缩进。
第二步，检查私钥路径和权限。IdentityFile写的路径是否存在，文件权限是否过松。macOS 和 Linux 下直接ls -l ~/.ssh/id_ed25519_personal看权限位。
第三步，确认公钥是否注册到了平台。很多平台允许同一个账户添加多个公钥，但公钥内容必须和私钥严格匹配。可以用ssh-add -l查看 agent 加载的密钥指纹，再和平台后台显示的指纹对比。
还有一个很容易被忽略的坑：如果 config 里没有写IdentitiesOnly yes，而 ssh-agent 里又同时加载了同一平台的多把密钥，SSH 会挨个尝试，第一把不匹配就报一次错再试下一把。成功虽然能成功，但调试时满屏错误噪音，失败时你根本不知道是哪把钥匙在捣乱。所以IdentitiesOnly yes一定要写。
4.2 提交身份为何依旧错乱
有次我把个人项目克隆到电脑上，确认了 Host 别名和 SSH 通道都没问题，推上去之后平台却显示“该作者未被识别为账号成员”。后来一查，是仓库 local 配置里根本没设user.email，实际用的是全局兜底邮箱。
排查身份问题，最快的方法是：
cd /path/to/repo git config --list --show-origin | grep user.然后逐项看user.name和user.email来自哪个文件。如果来自~/.gitconfig而不是.git/config，说明该仓库没有自己的身份配置。
还有一种情况：你在仓库里设置了user.name但忘了设user.email，平台查提交人时按邮箱匹配账号，结果头像对不上。所以两个字段一定要成对出现。
4.3 多平台凭证互相干扰
如果你的仓库地址走的是 HTTPS，而不是 SSH，那大概率会踩另一个坑：凭证管理器是按“域名”保存账号密码的。两个账号都在同一个平台域名下，后保存的凭证会把前面那个覆盖掉。今天拉公司仓库正常，明天拉个人仓库突然要求重新输入密码，来回切认证，非常崩溃。
我的建议是能走 SSH 就不走 HTTPS。SSH 的密钥是独立文件，天然支持并行，不存在凭证互相覆盖的问题。如果团队内部规定必须走 HTTPS，比如公司代理只开放 443 端口，那也有办法：在远程 URL 里显式加用户名。
git clone https://yourname@github.com/yourname/demo.git这样凭证管理器会按“用户名 + 域名”的组合键存储，两个账号就不打架了。但要注意，URL 里明文写用户名问题不大，不要写密码或令牌，令牌走正常的凭证提示输入。
4.4 常见问题速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
Permission denied (publickey) | IdentityFile 路径错误或权限过松 | 检查 config 路径，执行chmod 600 |
| 连接时尝试了多把密钥但仍然失败 | 缺少IdentitiesOnly yes | 在 config 对应 Host 块中加一行 |
| 首次连接提示 host key 验证失败 | known_hosts中记录过期 | 删除对应行或执行ssh-keygen -R 域名 |
| 提交记录显示为陌生人 | 仓库 local 身份未设置 | 在仓库内执行git config user.email |
| 全局身份污染所有仓库 | 全局配置了user.email | 清空或改为兜底，仓库内显式设置 |
| HTTPS 仓库频繁要求登录 | 凭证管理器同域名互相覆盖 | 改用 SSH 或 URL 中带用户名 |
| includeIf 未生效 | 路径末尾少斜杠或目录不匹配 | 检查gitdir:路径写法 |
排查时心态稳一点，按表格从上到下逐项验证，大部分问题十分钟内能定位。
5. 一点实操体会
这个流程跑通之后，我自己最深的体会是：不要在全局配置里写死user.email，这是八成身份问题的根源。之前吃过一次亏，新电脑上顺手设置了全局邮箱，个人项目推了一周才发现全挂错了身份，回头逐个改历史提交，折腾到半夜。
我现在的工作流是：全局只放通用偏好，公司目录和个人目录的includeIf各管各的，每拿到一个新仓库先跑一次git config --list --show-origin看一眼配置来源。刚开始感觉多一步很啰嗦，但习惯之后反而省心——所有仓库身份清清楚楚，换电脑、加新账号、离职交接都只是重复套模板的事。这套配置并不神奇，就是把 SSH 身份和提交身份分开治理，一次配完，后面基本不用再碰。
