1. 为什么要在Windows上同时配置三套Git环境
1.1 三个平台并存，才是开发者的日常
如果你只是偶尔往GitHub传点代码，那今天这篇你大概率用不上。但只要你经历过公司项目、个人开源、国内托管三线作战，你很快就会意识到一件事：电脑上只有一个默认SSH Key，根本没法在三家平台之间体面地共存。
我自己的真实场景是这样：公司在腾讯云上自建了GitLab，所有业务代码、内部组件库、配置文件都放在上面；自己的开源项目、博客源码放在GitHub；还有一些偏国内业务、需要加速拉取的小项目，放在Gitee上。以前每次切换到不同平台，都要重新改~/.ssh/config，或者干脆给每个仓库单独设置密钥，麻烦不说，还容易把密钥配错，权限报错能卡你一下午。
这套三平台并存的配置，核心解决的就是一个问题：让Git知道，连接github.com时用哪把钥匙，连接gitlab.company.com时用哪把钥匙，连接gitee.com时又用哪把钥匙。配好之后，你在三个平台之间切换提交、推送、拉取，完全不需要手动干预，就像同时拿着三把钥匙进了三扇门，Git自动帮你把门对上。
1.2 多仓库并存的底层逻辑：SSH协议是怎么认人的
要理解多平台共存，你得先搞清楚Git通过SSH连接远程仓库时，服务器是怎么验证你身份的。
SSH认证走的是非对称加密，你本地存私钥，服务器存公钥。当你执行git push时，客户端会拿着私钥去"敲门"，服务器用你预先上传的公钥来验明正身。这里有个关键点：Git本身并不过问你要连的是GitHub还是GitLab，它只负责把SSH请求发给对应的域名，至于用哪个密钥，是SSH客户端根据配置决定的。
如果你只有一个默认密钥id_rsa，那把公钥上传到GitHub可以，再上传到Gitee也可以，这本身不冲突。但问题出在你想在同一个平台注册两个账号（比如工作和个人），或者你换了电脑、重新生成密钥之后，旧公钥忘记在平台侧删除，就会出现"密钥到处飘"的混乱局面。更麻烦的是，如果你用的不是默认文件名，Git会一脸懵地告诉你Permission denied (publickey)。
所以三平台并存的本质，不是同时用三个Git客户端，而是一套Git环境下，用SSH Config把不同的域名路由到不同的私钥文件。把这一点想通了，后面所有配置步骤都顺理成章。
1.3 整体配置思路：先分钥匙，再写路由
我推荐的配置顺序，也是很多老手实际采用的标准流程：
- 生成三把独立的SSH密钥，分别命名为
id_ed25519_github、id_ed25519_gitlab、id_ed25519_gitee，互不干扰。 - 把三把公钥分别上传到三个平台的SSH Keys管理页面。
- 在
~/.ssh/config里写清楚每个Host对应哪个私钥文件。 - 用
ssh -T逐个测试连接，确认通了再推代码。 - 最后在仓库目录里单独配置
user.name和user.email，保证提交人身份跟随仓库走。
整个流程走下来大概十分钟。我用的是ed25519算法而不是传统的RSA，一是因为生成快，二是密钥长度短、安全性更高，GitHub和Gitee现在都完整支持，GitLab只要是较新的版本也没问题。如果你公司GitLab版本特别老，再退回去用rsa -b 4096也不迟。
2. 多SSH密钥生成与平台公钥配置实操
2.1 环境准备：确认Git版本和SSH客户端
在Windows上配置，第一步不是急着敲命令，而是确认你的环境是干净的。我见过太多人卡在ssh命令都输不了，或者密钥生成后根本找不到文件，基本都是环境没准备好。
打开PowerShell或者Windows Terminal，先看Git版本：
git --version只要输出类似git version 2.40.0.windows.1就没问题。然后确认SSH客户端可用：
ssh -VWindows 10 1809以后的系统自带OpenSSH客户端，如果你装了Git for Windows，它也会自带一套SSH工具。这里有个坑值得注意：系统自带的OpenSSH和Git自带的SSH，两套工具读配置文件的位置其实是一样的，都是C:\Users\你的用户名\.ssh\，但在某些环境下，版本差异会导致密钥算法兼容性问题。我一般建议直接用Git Bash来操作，路径统一，不容易出幺蛾子。
打开Git Bash后，检查.ssh目录是否存在：
ls -la ~/.ssh如果提示No such file or directory，说明还没创建过，后面生成密钥时会自动创建。如果目录里已经有id_rsa和id_rsa.pub，那说明之前配过默认密钥，不要慌，我们新生成的密钥文件用独立名字，和它井水不犯河水。
2.2 生成三把独立密钥，命名规范必须到位
这是整套配置里最核心的步骤，文件名直接决定了后面config文件好不好写。我强烈建议你在生成密钥的时候就按平台名来命名，别偷懒用id_rsa_1、id_rsa_2这种，否则两个月后你根本记不住哪把钥匙对着哪扇门。
依次执行以下三条命令，每条都会提示你输入存放路径和设置密码短语：
ssh-keygen -t ed25519 -C "github-xxx@example.com" -f ~/.ssh/id_ed25519_githubssh-keygen -t ed25519 -C "gitlab-xxx@company.com" -f ~/.ssh/id_ed25519_gitlabssh-keygen -t ed25519 -C "gitee-xxx@example.com" -f ~/.ssh/id_ed25519_gitee解释一下每个参数的作用：
-t ed25519：指定密钥算法为Ed25519，目前安全性和性能都很优秀。-C：注释信息，一般填你的邮箱，方便在平台后台识别这把钥匙是谁的。-f：指定生成的私钥文件路径，公钥会自动生成在同一个目录，文件名多一个.pub后缀。
命令执行过程中会问你是否设置passphrase（密码短语）。这里我建议设置一个简单的短语，成本极低，但能防止别人拿到你的私钥文件直接推代码。Git Bash下输入密码时不会显示任何字符，你以为是卡住了，其实是正常的。如果实在嫌麻烦，直接回车留空也可以，密钥文件就完全裸奔了。
生成完后，执行ls -l ~/.ssh，你应该能看到六把文件，三把私钥配三把公钥，数量对得上才算正常。
2.3 平台侧添加公钥：三个后台的操作差异
密钥生成完，你得把公钥内容填到平台后台去。在Git Bash里用cat命令查看公钥：
cat ~/.ssh/id_ed25519_github.pub输出形如：
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... github-xxx@example.com把这个内容完整复制，包括开头的ssh-ed25519和结尾的邮箱注释，然后分别去三个平台添加。
GitHub：登录后进入Settings->SSH and GPG keys->New SSH key，标题随便填（比如"Windows Work PC"），Key Type选Authentication Key，把公钥粘进去，保存。
GitLab：进入Preferences->SSH Keys，Key栏粘贴公钥，Title会自动带出注释，Expiration Date可以留空或设置一年后。注意GitLab保存公钥时格式校验很严格，开头结尾的空格都会被判为非法，粘贴时最好确认一下没有多余的换行。
Gitee：进入设置->安全设置->SSH公钥，把公钥粘进大输入框，标题自动生成，点确定。Gitee还支持同一个账号绑定多台电脑的公钥，每台设备生成一把独立的钥匙，管理起来也方便。
这一步有个细节：公钥添加完之后，不要马上关闭页面，等后面测试连通性通过了再关。万一测试失败，你还得回来检查是不是公钥粘贴出了问题。
3. 用config文件实现多Git平台自动匹配
3.1 config文件到底是什么，为什么它能救你
如果你只用默认的id_rsa点对点连接一个平台，那确实不需要config文件。但现在我们有三把钥匙、三个平台，Git当被告知git@github.com:xxx/repo.git时，它默认会去找~/.ssh/id_rsa，如果你没有这个文件，或者id_rsa对应的公钥没上传到GitHub，权限报错就来了。
~/.ssh/config就是SSH客户端的路由表。它会告诉SSH：当你试图连接某个Host时，使用哪个用户、哪个私钥、哪些参数。相当于你在小区门口放了一块指示牌，外卖小哥看到"3栋走A门、5栋走B门"，就能准确送达，不会敲错门。
在Git Bash里创建这个文件：
touch ~/.ssh/config然后用你用着顺手的编辑器打开，我一般在命令行直接写内容：
vim ~/.ssh/config不会vim也没关系，用记事本打开也行，但保存时记得编码选UTF-8，文件不要带.txt后缀。
3.2 完整配置示例，逐行拆解关键参数
下面是我用了很久的一份config配置，适配GitHub、GitLab、Gitee三平台：
# GitHub Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github IdentitiesOnly yes # GitLab（如果公司自建，把HostName换成实际域名/IP） Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_gitlab IdentitiesOnly yes # Gitee Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee IdentitiesOnly yes这里面每个参数的用途，我逐个说明：
Host：你访问远程仓库时使用的别名。对GitHub和Gitee来说，必须与真实域名保持一致，不能乱改，否则git命令里的URL会对不上。HostName：实际连接的域名或IP。如果你公司GitLab部署在内网，这里填内网地址；如果绑定了域名，填域名即可。User：SSH登录用户名。Git平台统一使用git，不需要改，也不需要填你的平台账号名。IdentityFile：指定该Host使用的私钥路径，这里的~会被自动解析成用户主目录。IdentitiesOnly yes：这个参数容易被忽略但非常重要。它强制SSH只使用config里指定的私钥，而不会一股脑把所有密钥都试一遍。很多"多密钥串门"的问题，就是没加这个参数导致的。
如果你还有第二个GitLab仓库组、第二个GitHub账号，其实就是在config里再加一组相同结构的配置，Host换一个别名即可。比如你有一个私有GitLab实例和公司GitLab，可以用Host gitlab-private.company.com区分。
3.3 测试连接：用ssh -T把三扇门都敲一遍
配置写完后，先检查config文件格式是否正确：
ssh -T git@github.com第一次连接会提示确认主机指纹，输入yes回车即可。如果配置正确，你会看到类似输出：
Hi xxx! You've successfully authenticated, but GitHub does not provide shell access.这就是"门已打开"的标志。接着测GitLab：
ssh -T git@gitlab.company.comGitLab会返回你的用户名：
Welcome to GitLab, @xxx!最后测Gitee：
ssh -T git@gitee.comGitee的返回比较个性：
Hi xxx! You've successfully authenticated, but Gitee does not provide shell access.三个平台全部返回包含successfully authenticated或者对应欢迎语的提示，说明路由已经全部打通。如果哪个平台报Permission denied (publickey)，优先检查三件事：config里的HostName写没写对、私钥路径写没写对、公钥有没有传到对应平台后台。我们后面单独开一节讲排错。
测试通过之后，还有一个增量操作值得做：把~/.ssh目录下的私钥文件权限收紧，Windows上一般默认就行，但如果你用的是WSL或者共享目录，注意别把私钥暴露给所有人。
4. 提交身份隔离与多仓库推送完整流程
4.1 为什么提交人的身份也要跟着平台走
密钥搞定了，很多人以为大功告成，结果第一次往GitLab推代码，提交记录里显示的作者居然是自己GitHub账号的邮箱。这就是提交身份没有隔离导致的。
Git记录提交作者，靠的是user.name和user.email这两个配置。如果你在安装Git时随手设置了--global的全局身份，那么所有仓库提交都会用这个身份，不管你是往公司GitLab推还是往个人GitHub推。这在多数场景下说得过去，但如果你希望GitHub上的提交显示个人邮箱、GitLab上的提交显示公司邮箱，或者干脆希望不同仓库用不同昵称，那就要用局部配置覆盖全局配置。
优先级的顺序是：仓库级配置 > 全局配置 > 系统配置。仓库级配置写在每个项目目录的.git/config里，只在当前仓库生效，正好可以用来做身份隔离。
4.2 用局部配置覆盖全局身份，避免提交错人
先看一眼你的全局配置是什么：
git config --global --list然后进入某个项目目录，单独设置这套仓库的提交身份。以我的公司GitLab项目为例：
cd /d/projects/company-app git config user.name "Zhang San" git config user.email "zhangsan@company.com"再切到个人GitHub项目：
cd /d/projects/my-blog git config user.name "zs-tech" git config user.email "zs.personal@example.com"设置完后用git config --local --list确认无误。这样每个仓库的提交记录都会被打上对应的身份标签，GitHub和GitLab后台统计的贡献图也不会串台。
这里我建议：全局配置只设一个兜底的通用身份，具体仓库一定要单独设局部身份。别嫌麻烦，这个习惯能避免很多尴尬。比如你某天在一个临时目录里初始化了仓库，忘了设局部身份，提交到GitHub后作者栏里出现了公司邮箱，负责开源社区维护的朋友可能就会私信问你"这是谁"。
4.3 从拉取到推送：三平台完整操作流程演示
配置全部就绪，我们拿一个真实场景完整走一遍。
场景一：从GitHub克隆并推送新分支
git clone git@github.com:zs-tech/my-blog.git cd my-blog git config user.name "zs-tech" git config user.email "zs.personal@example.com" git checkout -b dev/feature-xxx # 写代码、提交 git add . git commit -m "feat: add new post" git push origin dev/feature-xxx全程不需要指定密钥，SSH自动匹配，非常顺畅。
场景二：在已有GitLab仓库上改代码
git clone git@gitlab.company.com:backend/api-service.git cd api-service git config user.name "Zhang San" git config user.email "zhangsan@company.com" git pull origin main git checkout -b fix/logic-error git push origin fix/logic-error注意这里git@gitlab.company.com中的域名，必须和config里Host gitlab.company.com保持一致，SSH才能认路。
场景三：Gitee仓库的初始化推送
cd /d/projects/gitee-utils git init git remote add origin git@gitee.com:zs-tech/gitee-utils.git git add . git commit -m "init project" git push -u origin master推送之前别忘设置局部身份。Gitee的分支默认叫master还是main，取决于你在平台创建仓库时怎么选的，保持一致即可。
整套流程跑下来，你会发现一次公钥配置、永久无忧切换。以后新建项目只需要git clone或git init，再设置一下局部身份就行，完全不用再碰config文件。
5. 三平台共存常见问题排查实录
5.1 实战排错：权限拒绝、密钥错位、身份串台
我配置过不下十次多平台环境，也帮同事排查过不少问题，这里把最高频的几个问题整理成速查表，你可以直接对照着找原因。
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
Permission denied (publickey) | 对应平台的公钥未添加，或config路径写错 | 用cat ~/.ssh/id_ed25519_xxx.pub检查公钥内容，重新上传；确认config中IdentityFile路径与私钥实际位置一致 |
| GitHub能连，GitLab权限拒绝 | config里Host和HostName写错，或私钥匹配到旧文件 | 检查GitLab对应的Host段是否正确，确认IdentitiesOnly yes已加上 |
git@github.com: Permission denied (publickey)且提示no such identity | 私钥文件不存在或名字与config不一致 | 用ls -l ~/.ssh核对文件名，修改config或重新生成密钥 |
| 提交记录作者显示成别人 | 仓库级user.name/email没设置，用了全局配置 | 在项目目录执行git config user.name "期望名字"和git config user.email "期望邮箱" |
ssh: Could not resolve hostname xxx | 域名写错或存在代理导致DNS解析异常 | 检查config中HostName拼写，确认仓库URL中的域名与config的Host一致 |
Gitee连接时提示key already in use | 同一把公钥被绑到了其他账号 | 去之前绑定的账号后台删除旧公钥，或重新生成一个新密钥用于Gitee |
5.2 换电脑之后，如何快速把配置迁移过来
最常见的一个场景是换了新电脑。你在旧机器上配得好好的，新机器一git clone就报权限错误。原因很简单：新机器上没有私钥文件，平台后台绑定的公钥也对应的是旧私钥。
别急着重新生成密钥。有两种方案：方案一是把旧机器的.ssh整个目录拷贝到新机器对应位置，注意拷贝后私钥文件权限不能太宽松；方案二是在新机器上重新生成密钥，然后把新公钥分别添加到三个平台后台。
我个人的建议是方案二，理由很简单：旧私钥在过去的使用中可能已经暴露过，而且重新生成一次密钥的成本不到两分钟，换来的是更干净的密钥链。如果你实在懒得换，方案一也完全可用，记得把config文件一起拷过去。
新机器配置完成后，逐平台跑一遍ssh -T测试，通过之后再拉取代码。整个过程就是在重复本文第二节到第三节的步骤而已。
5.3 关于ssh-agent的坑：为什么有时候改了密钥不生效
还有一个容易被忽略的点是ssh-agent缓存。Windows的OpenSSH服务会在后台缓存你输入过的私钥，如果你在config里改了IdentityFile指向，但ssh-agent里缓存了旧私钥，连接时可能还是会拿出旧钥匙去试。
遇到这种情况，清空缓存再重新添加：
ssh-add -D然后重新添加需要的私钥：
ssh-add ~/.ssh/id_ed25519_github ssh-add ~/.ssh/id_ed25519_gitlab ssh-add ~/.ssh/id_ed25519_gitee执行完后再测连接就干净了。如果你发现ssh-add报错Could not open a connection to your authentication agent，说明ssh-agent进程没启动，先在PowerShell里启动服务：
Get-Service ssh-agent | Set-Service -StartupType Manual Start-Service ssh-agent然后再回到Git Bash执行ssh-add。
5.4 一个不太常见但很实用的小技巧
最后分享一个很多教程不会提的操作：如果你同一个项目需要同时推送GitHub和Gitee，可以不用手动push两次，直接给一个仓库加两个remote地址。前提是你已经配好了两把密钥，并且两个平台都绑定了对应公钥。
git remote add github git@github.com:zs-tech/my-tool.git git remote add gitee git@gitee.com:zs-tech/my-tool.git git push github main git push gitee main或者用git remote set-url origin --push --add把多个地址绑定到同一个remote，这样一条git push就能同时推送到两个平台。多平台协同发布时，这个技巧能省不少时间。
回到文章开头说的那个场景，现在我的日常开发已经完全离不开这套配置了。公司代码推GitLab，个人项目推GitHub，国内分发改Gitee，三套密钥井水不犯河水，配置一次基本能用到换电脑为止。整个过程最核心的认知就一句话：SSH不挑平台，只看域名路由。把Host、HostName、IdentityFile这三个字段的事搞明白，你甚至可以自由扩展到Bitbucket、自建Gitea、内部Gerrit，套路一模一样。
