Git 多账号多项目管理配置（GitHub+GitLab，附 Codex/Claude 提示词）

Pu847044653

769人浏览 · 2026-08-13 17:47:41

Pu847044653 · 2026-08-13 17:47:41 发布

本文以 工作账户使用 GitLab、个人账户使用 GitHub 为例，讲解本地多git账户多项目管理需要的设置和可能会踩的坑，并附上让 Codex 和 Claude code 这一类AI助手帮助我们管理的的常用prompt。理解 项目远程仓库用哪个账号认证 和 Commit 记录写的是谁 可能会出现差异，能有效避免私人commit推到工作git账户的尴尬（你也不想你的工作git group突然出现私人提交吧我的朋友）

本文涉及的 Git 配置、SSH 与 remote 用法均按2026年8月的 Git、GitHub、GitLab 和 OpenSSH 官方文档核对。

平时只有一个 Git 账号时，我们通常不会太关心“身份管理”：配置一次用户名和邮箱，仓库 clone 下来，之后正常 pull、push 就可以了。

但实际开发中可能遇到下面两种情况：

两个本地项目，分别属于两个不同账号：例如公司的项目推到工作 GitLab，自己的项目推到个人 GitHub；
一个本地项目，需要推送到两个远程仓库：例如同一套项目代码同时维护在 GitLab 和 GitHub。

这时如果仍然只依赖一套全局 Git 配置，很容易出现“提交邮箱串了”“SSH 用错账号”“代码推错仓库”等问题。

一、首先明确：SSH 和 HTTPS 有什么区别？

Git 连接 GitHub、GitLab 这类远程代码托管平台，常见有两种方式：HTTPS 和 SSH。

对比项	HTTPS	SSH
常见远程地址	`https://github.com/user/repo.git`	`git@github.com:user/repo.git`
认证方式	Token、OAuth、Credential Manager 等	SSH 公钥 / 私钥
首次配置	相对直观	需要先生成并配置 SSH Key
日常使用	凭据未缓存时可能需要认证	配置好后通常无需再输入账号、密码
多账号管理	可以实现，但依赖凭据管理	可以通过不同 SSH Key 和 Host 别名清晰区分
常见适用场景	临时使用、受代理或防火墙限制的环境	长期开发、多项目、多账号环境

这里的 SSH Key（SSH 密钥） 可以简单理解为一组配对的“钥匙”：

公钥可以交给 GitHub / GitLab；
私钥只保存在自己的电脑上，不能泄露。

以后执行 git pull、git push 时，服务器通过这组密钥确认“你是谁”。

SSH 配置完成后，日常开发通常不需要重复输入 GitHub / GitLab 的账号和密码，因此更适合长期开发环境。GitHub 已经不再支持用普通账号密码直接进行 Git 操作。

本文后续统一使用 SSH 举例。

二、关键概念：Git 其实有两套“身份”

多账号最容易混淆的地方：

远程认证身份：你有没有权限访问 GitHub / GitLab 上的仓库；
Commit 作者身份：这次提交在 Git 历史里记录的名字和邮箱是谁。

它们分别由不同配置控制：

例如：

git config --local user.name "Your Work Name"
git config --local user.email "work@company.com"

控制的是 之后创建的 Commit 记录谁是作者。

而下面这种配置（一般在~/.ssh/config或者C:\Users<用户名>.ssh\config能看）：

Host gitlab-work
    HostName gitlab.com
    User git
    IdentityFile ~/.ssh/id_ed25519_gitlab_work

控制的是连接 GitLab 时 使用哪一把 SSH 私钥进行认证。

三、GitHub 和 GitLab 能不能使用同一把 SSH Key？

可以。

如果一个账号在 GitHub，另一个账号在 GitLab，那么技术上可以把同一个 SSH 公钥分别添加到两个平台。因为 GitHub 和 GitLab 是两个独立的服务，各自维护自己的账号和 SSH 公钥映射。

例如同一个：

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

其中 id_ed25519.pub 可以同时添加到：

工作 GitLab；
个人 GitHub。

但是，从安全角度并不推荐这样做。

原因很简单：如果工作和个人共用一把私钥，一旦这把私钥泄露，两个平台都需要同时处理风险和轮换密钥。分开以后，风险边界会清楚很多。

推荐的方式是：

个人 GitHub  ──> personal SSH key
工作 GitLab   ──> work SSH key

因此，下面所有示例都使用两把独立 SSH Key。

这里有一个坑：如果是 两个 GitHub 账号，不要尝试把同一个 SSH Key 同时绑定到两个 GitHub 账号。GitHub 会提示 Key already in use，多账号应分别使用不同的 SSH Key。

四、准备两把 SSH Key：工作一把，个人一把

本文假设：

工作账户：GitLab
工作邮箱：work@company.com

个人账户：GitHub
个人邮箱：me@example.com

生成工作 GitLab Key：

ssh-keygen -t ed25519 -C "work@company.com" \
  -f ~/.ssh/id_ed25519_gitlab_work

生成个人 GitHub Key：

ssh-keygen -t ed25519 -C "me@example.com" \
  -f ~/.ssh/id_ed25519_github_personal

生成后大致会有：

~/.ssh/
├── id_ed25519_gitlab_work
├── id_ed25519_gitlab_work.pub
├── id_ed25519_github_personal
└── id_ed25519_github_personal.pub

其中：

.pub 结尾的是公钥，可以上传到平台；
没有 .pub 的是私钥，只保存在本机。

注意：如果本机已经存在 SSH Key，不一定需要重新生成。确认私钥仍然安全，可以继续将它用于 Company 或 Personal 账户。
如果希望工作与个人账户使用不同密钥，建议生成一组使用新文件名的密钥，不要覆盖现有文件。覆盖私钥后，原来配置了对应公钥的平台可能无法继续认证。

分别把：

id_ed25519_gitlab_work.pub       -> 工作 GitLab
id_ed25519_github_personal.pub   -> 个人 GitHub

添加到对应平台账号的 SSH Keys 设置中。

将公钥添加到 GitHub

登录你的 GitHub 账户。
点击页面右上角的个人头像，在下拉菜单中选择 Settings（设置）。
在左侧边栏的 Access（访问）部分，点击 SSH and GPG keys。
点击页面右侧的 New SSH key 按钮。
填写密钥信息：
- Title（标题）：输入一个便于识别该密钥的名称，例如 Work Laptop；
- Key（密钥）：粘贴前面复制的公钥内容。
点击 Add SSH key 完成添加。

也可以直接打开 GitHub SSH Keys 设置页面。

将公钥添加到 GitLab

登录你的 GitLab 账户。
点击页面右上角的个人头像，在下拉菜单中选择 Edit profile（编辑个人资料）或 Settings（设置）。
在左侧边栏中选择 SSH Keys（SSH 密钥）。
点击 Add new key（添加新密钥）按钮。
填写密钥信息：
- Key（密钥）：粘贴前面复制的公钥内容；
- Title（标题）：输入一个便于识别该密钥的名称。
点击 Add key 完成添加。

Codex 提示词：生成两套 SSH Key

帮我为工作 GitLab 和个人 GitHub 分别生成 ed25519 SSH key，文件名使用 id_ed25519_gitlab_work 和 id_ed25519_github_personal。不要覆盖已有密钥，完成后告诉我需要上传哪两个公钥文件。

五、用 SSH Host 别名把“账号”和“密钥”绑定起来

接下来编辑：

~/.ssh/config

加入：

Host gitlab-work
    HostName gitlab.com
    User git
    IdentityFile ~/.ssh/id_ed25519_gitlab_work
    IdentitiesOnly yes

Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github_personal
    IdentitiesOnly yes

这里第一次出现几个 SSH 配置项，可以简单理解为：

Host：本机自己定义的别名；
HostName：真正要连接的服务器；
IdentityFile：这个别名固定使用哪把私钥；
IdentitiesOnly yes：明确要求 SSH 只使用指定身份，避免 ssh-agent 中存在多把密钥时试错或串用。

如果公司使用的是自建 GitLab，例如 gitlab.company.com，只需要把：

HostName gitlab.com

改成公司的 GitLab 域名。

现在测试两边：

ssh -T git@gitlab-work
ssh -T git@github-personal

如果认证成功，说明 SSH 这一层已经配置完成。

以后远程仓库地址也不再使用：

git@github.com:myname/project.git

而是使用我们刚定义的 Host 别名：

git@github-personal:myname/project.git
git@gitlab-work:company/project.git

这样看到 remote 地址时，就能直接判断它会走哪个账号、哪把 Key。

Codex 提示词：配置 SSH Host

帮我在 ~/.ssh/config 中配置 gitlab-work 和 github-personal，分别使用现有的工作/个人 SSH key；保留已有配置，设置 IdentitiesOnly yes，并验证两个 SSH 连接。

六、场景一：两个本地项目，分别推送到两个账号

这是最常见的情况：

~/projects/work-project      -> 工作 GitLab
~/projects/personal-project  -> 个人 GitHub

整体关系如下：

这时最稳妥的做法是：每个仓库都设置自己的 local Git identity，同时 remote 使用对应 SSH Host。

6.1 工作项目：使用工作身份

进入工作项目：

cd ~/projects/work-project

或者你想要在某个远程项目的基础上开发，尚未克隆远程项目时，直接 git clone 然后进入项目文件夹即可。

设置当前仓库的 Commit 身份：

git config --local user.name "Your Work Name"
git config --local user.email "work@company.com"

这里特意写出 --local，表示配置只作用于当前仓库。

实际上，在 Git 仓库中执行：

git config user.name "Your Work Name"

没有指定 --global、--system 等范围时，写配置默认就是 local。也就是说，上面两种写法效果相同。

本文仍然建议显式写 --local，因为在工作/个人账号混用的电脑上，这样意图更明确，也更不容易误改全局身份。

然后设置工作远程仓库：

git remote set-url origin \
  git@gitlab-work:company/work-project.git

如果当前还没有 origin（意思是当前本地仓库的配置中，还没有一个名为 origin 的远程地址，有可能你本地仓库还没建）：

git init ##创建本地仓库
git remote add origin \
  git@gitlab-work:company/work-project.git

最后推送：

git push -u origin main

注意，这里若能推送成功，隐含了以下条件之一：

是远程仓库为空；
本地是从该远程仓库克隆的，两边具有共同历史；
远程 main 的提交已经包含在本地历史中。

如果有冲突，按需再去问AI怎么解决你这些冲突，本文不做详细讨论。

Codex 提示词：配置工作项目

帮我把当前仓库配置为工作 GitLab 项目：仓库级设置工作 user.name/user.email，origin 使用 gitlab-work SSH Host。不要修改全局 Git 配置，完成后验证 identity 和 remote。

6.2 个人项目：使用个人身份

进入个人项目：

cd ~/projects/personal-project

设置个人 Commit 身份：

git config --local user.name "Your Personal Name"
git config --local user.email "me@example.com"

设置个人 GitHub remote：

git remote set-url origin \
  git@github-personal:myname/personal-project.git

如果还没有 origin：

git remote add origin \
  git@github-personal:myname/personal-project.git

推送：

git push -u origin main

Codex 提示词：配置个人项目

帮我把当前仓库配置为个人 GitHub 项目：仓库级设置个人 user.name/user.email，origin 使用 github-personal SSH Host。不要修改全局 Git 配置，完成后验证 identity 和 remote。

七、怎么确认项目没有“串身份”？

配置完成后，不要急着提交，先检查一次。

查看当前仓库最终使用的名字和邮箱：

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

如果是工作项目，理想情况下应该看到类似：

file:.git/config    Your Work Name
file:.git/config    work@company.com

再检查 remote：

git remote -v

工作项目应该类似：

origin  git@gitlab-work:company/work-project.git (fetch)
origin  git@gitlab-work:company/work-project.git (push)

个人项目应该类似：

origin  git@github-personal:myname/personal-project.git (fetch)
origin  git@github-personal:myname/personal-project.git (push)

最后再检查 SSH：

ssh -T git@gitlab-work
ssh -T git@github-personal

这样就分别验证了：

Commit 身份 -> git config
远程地址    -> git remote
认证身份    -> SSH

Codex 提示词：检查账号是否配置正确

检查当前 Git 仓库的 user.name、user.email、配置来源、remote 和 SSH 认证，判断是否存在工作/个人账号串用；只检查并说明问题，不要修改配置。

八、场景二：一个本地项目，同时推送 GitLab 和 GitHub

第二种情况是：同一个本地 Git 仓库需要维护两个远程副本。

例如：

                   -> 工作 GitLab
本地 project ------|
                   -> 个人 GitHub

这里推荐的做法不是反复修改 origin，而是给两个远程仓库分别起名字：

Git 中的 remote（远程仓库配置） 可以简单理解为“给远程地址起一个本地名字”。大家最熟悉的 origin 只是默认常用名称，并不是必须只能叫 origin。

添加工作 GitLab：

git remote add work \
  git@gitlab-work:company/project.git

添加个人 GitHub：

git remote add personal \
  git@github-personal:myname/project.git

查看结果：

git remote -v

应该能看到类似：

work      git@gitlab-work:company/project.git (fetch)
work      git@gitlab-work:company/project.git (push)
personal  git@github-personal:myname/project.git (fetch)
personal  git@github-personal:myname/project.git (push)

以后分别推送：

git push work main
git push personal main

这种方式的优点是非常直观：

git push work main 明确表示推到工作 GitLab；
git push personal main 明确表示推到个人 GitHub；
某一个平台失败时，可以单独重试，不影响另一个 remote 的管理。

Git 官方文档对于“不同位置”的远程也建议使用独立 remote，因此本文不建议为了少敲一条命令，把 GitHub 和 GitLab 两个不同仓库混在同一个 remote 中。

Codex 提示词：一个项目配置两个远程仓库

帮我给当前仓库配置两个 remote：work 指向工作 GitLab，personal 指向个人 GitHub，分别使用 gitlab-work 和 github-personal SSH Host。不要修改提交历史和全局 Git 配置，完成后验证 remote。

可选：一条命令同步到两个远程仓库

如果 GitLab 和 GitHub 上的仓库只作为内容完全一致的两个副本，也可以给同一个 remote 配置多个推送地址：

git remote add sync \
  git@gitlab-work:company/project.git

git remote set-url --add --push sync \
  git@gitlab-work:company/project.git

git remote set-url --add --push sync \
  git@github-personal:myname/project.git

以后执行一条命令即可依次推送到两个地址：

git push sync main

需要注意对于这种推送：一个远程推送成功、另一个失败时，成功的推送不会自动回滚。由于独立 remote 更方便查看状态和单独重试，本文仍推荐优先使用前面的 work 和 personal 方案。

九、一个项目推两个远程时，Commit 身份会不会自动切换？

不会。

这是另一个很重要的概念。

假设当前仓库配置的是：

git config --local user.name "Your Work Name"
git config --local user.email "work@company.com"

然后执行：

git commit -m "update"

这个 Commit 创建出来时，作者信息已经写入 Git 的 Commit 对象。

接下来即使分别执行：

git push work main
git push personal main

两个平台收到的仍然是同一个 Commit，其中的作者姓名和邮箱不会因为“推到了不同 remote”而自动变化。

可以理解为：

所以：

SSH Key 决定“有没有权限推到这个远程仓库”，user.name/user.email 决定“这个 Commit 记录的是谁”。

如果同一个项目本身属于工作项目，一般就应该使用工作身份创建 Commit；即使它还需要同步到另一个远程，也不会因此自动变成另一个作者。

另外，如果准备把公司代码同步到个人 GitHub，一定要先确认公司的代码资产、保密、开源和仓库管理政策是否允许。这个问题已经超出了 Git 配置本身的范围。

十、推荐本地结构

对于“工作 GitLab + 个人 GitHub”，推荐最终保持下面这样的结构：

参考资料

Git 官方文档：git config 配置范围、--local 与 --global
https://git-scm.com/docs/git-config/zh_HANS-CN.html
Pro Git：Git 用户身份与 user.name / user.email
https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup
Git 官方文档：git remote 及多个远程仓库的管理
https://git-scm.com/docs/git-remote/zh_HANS-CN.html
GitHub Docs：使用 SSH 连接 GitHub
https://docs.github.com/en/authentication/connecting-to-github-with-ssh
GitHub Docs：添加 SSH Key
https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account
GitHub Docs：在一台机器上管理多个 GitHub 账号
https://docs.github.com/en/account-and-profile/how-tos/account-management/managing-multiple-accounts
GitHub Docs：Key already in use 说明
https://docs.github.com/en/authentication/troubleshooting-ssh/error-key-already-in-use
GitLab Docs：使用 SSH Key 访问 GitLab
https://docs.gitlab.com/user/ssh/
OpenSSH ssh_config 手册：IdentityFile 与 IdentitiesOnly
https://man.openbsd.org/ssh_config
GitHub Docs：管理远程仓库与 Git 操作的认证方式
https://docs.github.com/en/get-started/git-basics/managing-remote-repositories