git同一台电脑配置多个账号【教程】

git同一台电脑配置多个账号【教程】

开门见山，先说结论：这事儿能办，但得把三件事儿绑在一块儿处理——清除全局的 user.name 和 user.email、为每个账号生成独立的 SSH 密钥、再用 ~/.ssh/config 文件把 Host 别名和对应的私钥绑定起来。这三步，少了哪一环都不行，否则不是推送时给你来个 Permission denied (publickey)，就是提交记录里作者信息张冠李戴。

为什么 git config --global --unset user.name 必须做

这里有个常见的误区。Git 在确定提交作者信息时，遵循的是“全局优先，本地补充”的继承逻辑。换句话说，如果你全局配置里还留着旧信息，那么即便你为某个仓库单独设置了 git config --local user.name，只要克隆仓库后忘了第一时间进去配置，第一次提交就会直接套用全局值。结果就是，代码明明推到了 GitHub，提交者却显示成你另一个平台的账号名，场面一度十分尴尬。

• 动手前，先用 git config --global --list 命令看一眼，确保输出结果里已经没有了 user.name 和 user.email 的踪影。
• 别轻信“我只用本地配置就够”的说法。很多图形化工具，比如 VS Code 内置的 Git 功能，有时会跳过本地配置，直接读取全局值。
• 清除了全局配置之后，每个仓库都得“独立门户”。你需要进入项目目录，老老实实地执行一遍 git config --local user.name "xxx" 和 git config --local user.email "xxx@xxx.com"。

ssh-keygen 命名不带下划线或点，否则 Windows 下可能失效

给密钥文件起名也是个技术活，尤其在 Windows 环境下。Windows 的 OpenSSH 客户端对文件名比较挑剔，像 id_rsa_github.com 或 id_rsa-github 这种带点或短横线的名字，在某些版本的 Git for Windows 里可能会被直接忽略。经过实测，最稳妥的命名规则是：只用字母、数字和下划线，并且别用数字开头。

• 正确示范：ssh-keygen -t rsa -C "me@github.com" -f ~/.ssh/id_rsa_gh
• 错误示范：id_rsa.github、01_gitee、id-rsa-gitlab
• 生成密钥时，设置密码那一步，除非公司有强制要求，否则建议直接按回车跳过。不然每次推送代码都得输一遍密码，实在影响效率。
• 把公钥上传到平台前，最好用 cat ~/.ssh/id_rsa_gh.pub 命令检查一下。确认它以 ssh-rsa AAAA... 开头，内容完整，没有奇怪的乱码或被意外截断。

~/.ssh/config 的 Host 名必须和 git remote URL 里的主机名完全一致

很多人都在这一步卡住。明明在 config 文件里写了 Host github.com，用 git@github.com:xxx/yyy.git 克隆仓库，却发现 SSH 还是走了默认的密钥。问题出在哪？在于 SSH 的匹配逻辑非常“耿直”：它只认远程地址（URL）中 @ 符号后面的第一个词作为主机名，并且不会去解析后面的路径。

• 如果你的远程地址是 git@github.com:xxx/yyy.git，那么 config 文件里的 Host 就必须老老实实写成 github.com（不能自己起个别名如 mygithub）。
• 如果你想使用自定义的别名（比如为了避免修改所有现有的远程地址），那就得把远程地址改成 git@mygithub:xxx/yyy.git，同时确保 config 里对应写着 Host mygithub。
• 这里要分清：Host 字段是你用来匹配的“钥匙”，而 HostName 字段才是真正的“锁”——也就是实际要连接的服务端域名，例如 HostName github.com。至于 IdentityFile（私钥路径），推荐使用正斜杠，Windows 系统也认这个写法：IdentityFile ~/.ssh/id_rsa_gh。
• 配置完成后，一定要测试。运行 ssh -T git@github.com，如果看到返回 Hi xxx! 的欢迎信息，才算大功告成。如果还是提示权限被拒绝，那多半是 config 文件没被加载，或者路径写错了。

git remote add 时 URL 主机名要和 config 对齐

这是整个流程中最容易被忽略的衔接点。config 文件配置得再完美，如果你在克隆仓库或添加远程地址时，依然使用了原始的域名，SSH 客户端根本不会去查询你精心设置的别名映射。

• 举个例子：假设你在 config 里定义了 Host gitee-work，那么添加远程仓库时，地址就必须是 git@gitee-work:username/repo.git，而不能是 git@gitee.com:...。
• 对于已经存在的仓库，想切换使用的账号？先执行 git remote set-url origin git@gitee-work:username/repo.git 修改远程地址，然后再推送。
• 别完全依赖 GitHub Desktop 或 Sourcetree 这类图形化客户端自动识别，它们经常缓存旧的远程地址。手动修改后，最好重启一下客户端。
• 最后，用 git remote get-url origin 命令检查一下当前的远程地址，确保输出信息里的主机名，和你 config 文件中定义的 Host 项严丝合缝地对得上。

说到底，真正的难点从来不是生成密钥或者写 config 文件本身，而是要求每个环节的“命名”和“地址”必须像齿轮一样精确咬合：config 里的 Host、remote 地址里的主机名、git config --local user.email 设置的邮箱，这三者必须毫无偏差地指向同一个账号身份。只要其中一环对不上，系统就只会给你抛出一句冷冰冰的 “Permission denied” 或 “author mismatch”，至于到底是哪一环断了，它可不会告诉你。