SourceTree 3.4.26 多仓库管理：GitHub 与 GitLab 账号配置实战

很多开发者在同时使用 GitHub 和 GitLab 时，最头疼的不是写代码，而是把本地仓库跟多个远程平台顺畅地连起来。SourceTree 3.4.26 是我用了很久的 Git 图形化客户端，它的仓库管理、分支可视化和提交历史展示都做得相当顺手。这篇文章就围绕一个核心场景展开：在一台机器上，把 GitHub 和 GitLab 的账号完整地配置进 SourceTree，实现两种平台的仓库都能正常拉取、推送、切换分支。

文章适合三类人看：刚接触 SourceTree 的小白、公司内网用 GitLab 同时自己又玩 GitHub 的开发者，以及被“每次 push 都要输密码”折磨到崩溃的懒人。我会从环境准备讲到账号添加，再到多账号并存时的身份切换和报错排查，整个过程都会标注关键参数和操作理由，你跟着一步步做就能复现。

1. 项目概述：SourceTree 3.4.26 与多平台账号配置

1.1 为什么选 SourceTree 管理 GitHub 和 GitLab

很多开发者一开始习惯用命令行操作 Git，我承认git pull、git push确实够快，但遇到分支关系复杂、提交历史交错、或者需要对比两个版本差异的时候，纯命令行的视觉负担其实很大。SourceTree 的价值在于把这些操作可视化了——分支用线条画出来，提交记录一眼扫过去就能定位，暂存区和工作区的变化也有清晰的标色。经过多次版本迭代，3.4.26 这个版本在稳定性上表现不错，尤其是对 Windows 和 macOS 双平台的支持都比较均衡，日常操作基本没遇到过崩溃。

选择它在 GitHub 和 GitLab 之间做统一管理的另一个现实原因，是很多团队内部用 GitLab 做代码托管，而开发者个人又习惯把开源项目放在 GitHub。如果每次都手动切换 SSH 配置、或者用命令行临时指定账号，操作成本会随仓库数量上升。SourceTree 自带了账号管理面板，可以把多个远程平台的凭证集中保存，克隆、拉取、推送时自动匹配，省心不少。

1.2 3.4.26 版本的关键特性

3.4.26 这个版本有几个实际体验上的特点值得先说清楚。第一，它对 Git 2.x 的兼容性较好，仓库较大时刷新速度也还能接受，不像早期版本那样动不动就卡在索引阶段。第二，它的远端仓库管理界面集成度不错，可以直接预览远程分支、删除远程分支、设置 upstream，这些操作在命令行里往往要敲一长串参数，图形界面里点两下就完成了。

还有一个容易被忽略的点：SourceTree 在 3.x 之后强化了对个人访问令牌（Personal Access Token）的支持。这在配置 GitLab 账号时尤其重要，因为 GitLab 很早就不再接受密码直接走 HTTPS 认证，你必须用令牌代替密码。如果还在用旧版本，配置流程可能会遇到认证失败。所以如果你目前是 3.4.26 之前的版本，我建议先升级到这个版本，后面的操作会顺畅一些。

2. 环境准备：装好工具再动手

2.1 安装 SourceTree 前的三项准备

我习惯把准备工作分成三块：Git 环境、SSH 密钥、平台账号。这三块里最容易卡住新手的是 Git 环境。SourceTree 虽然自带了一个嵌入式 Git 版本，但我不太推荐直接用它默认的那套，原因是它和内网 GitLab 使用的某些 Git 钩子或者 CRLF 转换策略偶尔会出现兼容性问题。更稳妥的做法是提前安装独立的 Git for Windows 或 macOS 自带的 Git，然后在 SourceTree 的设置里指定使用系统 Git。

具体操作路径是：打开 SourceTree 的“工具”菜单，进入“选项”，在“Git”标签页里把 Git 版本从“嵌入式”改为“系统”。改完之后重启 SourceTree，它会重新读取仓库的 Git 配置。这一步做完，后续的账号配置才有稳定的执行环境。

第二个准备是确认网络环境能正常访问两个平台。这里的访问指的是你所在网络下 GitHub 和 GitLab 是否都能打开网页、能否完成 API 请求。SourceTree 在添加账号和刷新仓库信息时会调用平台的接口，如果网络不通，后续所有配置都无从谈起。

第三个准备是把两个平台的用户名、邮箱记下来。很多人忽略这点，Git 提交记录的 Author 信息就是靠它来标识的。如果你在 GitHub 上用的邮箱和公司 GitLab 里的邮箱不一致，建议在本地仓库里分别配置user.name和user.email，避免提交到不同平台时显示成两个完全不相干的人。

2.2 SSH 密钥生成与平台登记

账号配置的底层通信方式，我强烈建议走 SSH 而不是 HTTPS。原因很简单：SSH 密钥一次性配置好之后，几乎不需要再输入凭证，而 HTTPS 方式每次拉取推送都要依赖密码管理器或者令牌存储，一旦缓存过期又会弹认证框。对于同时挂 GitHub 和 GitLab 两个平台的场景，SSH 还支持通过配置文件区分不同平台的密钥，管理起来更灵活。

生成密钥的标准命令是：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

执行后会提示你选择保存路径。默认路径是~/.ssh/id_rsa，如果你只用一个密钥同时配两个平台，直接用默认路径就行。但如果想为 GitHub 和 GitLab 分别生成独立的密钥，建议在生成时手动指定文件名，比如：

ssh-keygen -t rsa -b 4096 -C "github_work" -f ~/.ssh/id_rsa_github ssh-keygen -t rsa -b 4096 -C "gitlab_work" -f ~/.ssh/id_rsa_gitlab

这里涉及一个关键认知：SSH 密钥只是身份的凭证，你把它登记到哪个平台，就代表你在这个平台上使用这个密钥代表你的身份。两个平台可以共用同一个公钥，也可以各自用不同的公钥，都不会冲突。唯一要注意的是私钥文件权限必须收紧，Linux/macOS 下设置chmod 600 ~/.ssh/id_rsa是基本操作，Windows 下则要注意不要把私钥文件放到能被其他用户读取的目录里。

生成后，查看公钥内容：

cat ~/.ssh/id_rsa.pub

把输出的一大段ssh-rsa AAAA...全部复制下来。接下来分别登录 GitHub 和 GitLab，在各自的设置页面里找到 SSH Keys 或 SSH 密钥 入口，粘贴公钥并保存。GitHub 的位置是 Settings → SSH and GPG keys → New SSH key，GitLab 的位置是 Preferences → SSH Keys。这一步做完，SSH 身份这一层就打通了。

2.3 验证 SSH 连通性

登记完公钥后，不要急着打开 SourceTree，先用命令行验证一下连通性，可以省去后面排查的时间。GitHub 和 GitLab 都是用 SSH 协议来握手，验证命令分别是：

ssh -T git@github.com ssh -T git@gitlab.com

如果密钥配置正确，GitHub 会返回类似Hi username! You've successfully authenticated, but GitHub does not provide shell access.的信息，GitLab 会返回Welcome to GitLab, @username!之类的提示。注意这里有个容易误解的点：SSH 连接中使用的用户名必须是git，而不是你自己的 GitHub 或 GitLab 用户名。这是平台固定的 SSH 服务账号，真正识别身份靠的是密钥本身。

如果验证失败，最常见的提示是Permission denied (publickey)。这个提示通常意味着 SSH 客户端没有找到匹配的私钥，或者找到的私钥没有被平台登记。你可以用ssh -vT git@github.com查看详细日志，日志中Offering public key这一行会显示具体发送了哪个公钥文件，对照平台登记的公钥就能判断问题在哪。

另外，如果你用了独立文件名生成密钥，需要检查~/.ssh/config文件是否做了映射。举个例子：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github Host gitlab.com HostName gitlab.com User git IdentityFile ~/.ssh/id_rsa_gitlab

这个配置文件的作用是让 SSH 客户端在连接不同域名时选用对应的私钥。没有它的话，SSH 只会尝试默认的id_rsa，自定义文件名的密钥永远不会被使用，这就是很多人配完密钥仍然报 Permission denied 的隐藏原因。

3. 配置 GitHub 账号：OAuth 与 Token 两条路

3.1 首选 OAuth 方式：浏览器授权

SSH 配置好之后，SourceTree 里面的账号其实就很好添加了。打开 SourceTree，在顶部工具栏找到仓库名称右边那个带人形图标的按钮，或者直接从菜单栏进入“工具 → 选项 → 认证”，都能打开账号管理界面。点击“添加账户”，这时会弹出一个对话框，里面有托管主机、认证方式、用户名、密码等字段。

对于 GitHub，最省事的其实是 OAuth 方式。在“托管主机”下拉里选择 GitHub，然后 SourceTree 会直接调起浏览器打开 GitHub 的授权页面。你只需要确认授权的应用名称和权限范围，点击 Allow，浏览器会跳转回 SourceTree 并完成凭证保存。整个过程中不需要输入任何密码，因为授权是建立在你的 GitHub 登录会话基础上的。

OAuth 的方式之所以值得优先使用，是因为 GitHub 在 2021 年之后就不再支持账号密码直接走 Git 操作认证了，即使用密码框里填密码，也会被拒绝。OAuth 帮 SourceTree 换取了一个短时效的访问令牌存在本地，SourceTree 后续的 API 调用和 Git 操作都通过这个令牌进行。如果你在浏览器里已经登录了 GitHub，整个过程不到一分钟就能完成。

还有一个细节：在添加账户对话框中，SourceTree 会问你“首选使用 HTTPS”还是“首选使用 SSH”克隆。如果你已经配好了 SSH，这里一定要选 SSH。这样之后从 GitHub 克隆仓库时，SourceTree 会自动拼出git@github.com:...这样的地址，走的就是你刚才验证过的 SSH 通道，Git 操作时会自动匹配密钥，完全不用再输入凭证。

3.2 Token 方式：适合受限环境

OAuth 不是任何时候都可用。有些企业网络或者公司策略会限制第三方应用的 OAuth 回调，或者你根本不希望把 SourceTree 挂在 GitHub 账号的授权应用列表里。这时候可以选择用个人访问令牌（Personal Access Token）来配置。

先在 GitHub 网站上生成令牌：Settings → Developer settings → Personal access tokens → Tokens (classic) → Generate new token。生成时建议勾选repo（完整控制私有仓库）、workflow（如果仓库里有 GitHub Actions 工作流文件需要推送更新）和read:org（读取组织信息，非必需但建议勾上）。Note 字段随便填，方便后续识别这个令牌是给哪个客户端用的。Expiration 建议根据你的使用频率设，如果只是偶尔拉取，30 天就够了；如果想长期省心，可以选 90 天或更长时间，GitHub 也允许创建不过期令牌，但不推荐，因为泄露风险会随着时间累积变大。

拿到令牌后，回到 SourceTree 的添加账户界面，托管主机选 GitHub，认证方式选“基础”或“HTTPS”，用户名填你的 GitHub 用户名，密码框里粘贴这个令牌。注意，SourceTree 的界面里写的虽然是 password，但这里输入的一定是令牌，不是账号密码。

Token 方式下克隆仓库时也要稍微留意一下：仓库地址要用 HTTPS 形式，也就是https://github.com/用户名/仓库名.git。SourceTree 会把这个令牌保存在 Windows 凭据管理器或 macOS 钥匙串里，Git 操作时自动带上进行认证。如果你发现每次操作还是被要求输入密码，多半是 SourceTree 的嵌入式 Git 没有正确读取凭据，切到系统 Git 后通常就解决了。

3.3 克隆仓库验证配置

账号添加完成后，最快的验证方式是直接克隆一个仓库。在 SourceTree 主界面点击“克隆/新建”，在源 URL 一栏粘贴你要克隆的 GitHub 仓库地址，如果走 SSH 就是git@github.com:用户名/仓库名.git，走 HTTPS 就是https://github.com/用户名/仓库名.git，目标路径选择本地目录，点击“克隆”即可。

克隆过程中观察 SourceTree 下方的状态栏和输出日志。SSH 方式下，首次连接可能出现一个指纹确认的弹窗，询问你是否信任github.com的 ECDSA 密钥指纹。这里直接点确认即可，这个机制是为了防止中间人攻击，指纹也可以去 GitHub 官方文档里核对。克隆完成后，尝试做一次提交并推送，如果推送无需输入任何凭证且成功，说明 GitHub 账号配置已经彻底打通。

这里顺便提一个我实际遇到过的坑：如果 SourceTree 里添加了 GitHub 账号，同时又通过 Windows 凭据管理器存了一套旧的 GitHub 密码，推送时会优先走旧的缓存凭证，导致认证失败。解决办法是把凭据管理器里 GitHub 对应的旧记录删掉，让 SourceTree 接管认证。Windows 下输入rundll32.exe keymgr.dll,KRShowKeyMgr可以打开凭据管理器，找到git:https://github.com删除即可。

4. 配置 GitLab 账号：Token 是唯一入口

4.1 在 GitLab 上申请个人访问令牌

GitLab 的账号配置思路跟 GitHub 类似，但细节上有几个不一样的坑。首先是平台的差异：GitLab 有官方托管版（gitlab.com）和很多公司内部自建的社区版/企业版，两者的界面语言、功能位置略有不同，但基本原理一致。其次，GitLab 对密码认证的限制更严格，从很早的版本开始就不再接受用户名加密码的 HTTPS Git 认证方式，必须使用个人访问令牌。

先说说怎么在 GitLab 上拿到令牌。登录 GitLab 后，点击左下角的用户头像，进入 Preferences（偏好设置），在左侧菜单里找到 Access Tokens（访问令牌）。填写令牌名称，勾选权限范围，常见的组合是read_repository（读取仓库）和write_repository（写入仓库）。如果还需要调用 GitLab API 做自动化操作，可以加上api范围，但纯粹用于 SourceTree 日常拉取推送的话，read_repository和write_repository就足够了。注意有一个expires_at字段，GitLab 支持设置令牌过期时间，但也允许不设置，不设置的令牌会一直有效，只是安全性下降。我个人建议公司内网的 GitLab 令牌不要设置过期时间，否则每几个月就要重新配一次 SourceTree，效率很低；个人项目则建议设 30 天。

创建令牌后，GitLab 会把令牌明文显示一次，之后就不再可见。务必立刻复制保存到临时文件或密码管理器里。这一步我吃过亏，创建完忘了复制，刷新页面后只能重新生成，等于白白多了一次权限重建。

4.2 在 SourceTree 中配置 GitLab 账号

拿到令牌后，回到 SourceTree 的添加账户界面。托管主机下拉框里，官方 GitLab 会直接列出 GitLab 选项，公司自建的 GitLab 则通常需要选择“自定义”或“GitLab”后手动填写服务器地址。这里有一个关键点：SourceTree 是通过 GitLab 的 API 来校验账号信息的，所以它要求你填写的是 GitLab 实例的 API 端点。官方版的 API 地址就是https://gitlab.com/api/v3/或https://gitlab.com/api/v4/，自建版的地址是https://你的GitLab域名/api/v4/。

我建议在 SourceTree 里认证方式选择“HTTPS”，用户名填你的 GitLab 用户名，密码框填个人访问令牌。填完之后点击“刷新”或“验证”，SourceTree 会调用 API 校验令牌有效性。如果你的 GitLab 实例版本比较老，遇到报错信息里出现login failed. check api token or gitlab version之类的提示，那基本可以判断是 API 版本不匹配。旧版 GitLab 用/api/v3/，新版用/api/v4/，SourceTree 默认可能探测不到，需要你手动在设置里指定。

这里要专门提醒一下自建 GitLab 的用户：公司内网 GitLab 如果用了自签名证书，SourceTree 调用 API 时可能会因为证书不受信任而报错。这种情况处理起来稍微麻烦，一个可行方案是把自签名证书导入操作系统信任链，另一个方案是在 SourceTree 的 Git SSL 设置里暂时关闭校验，但后者有安全风险，我只建议在完全可信的内网环境使用，而且只作为临时调试手段。

4.3 自建 GitLab 与官方版的差异处理

自建 GitLab 和官方版在 SourceTree 配置中的差异，主要体现在远程仓库地址拼接上。官方版仓库地址是https://gitlab.com/用户名/仓库名.git或git@gitlab.com:用户名/仓库名.git，自建版则是https://你的GitLab域名/用户名/仓库名.git。如果你按我前面的步骤配好了 SSH，自建 GitLab 的 SSH 地址就是git@你的GitLab域名:用户名/仓库名.git。

这里有一个容易出问题的地方：如果公司内网 GitLab 的 SSH 端口不是默认的 22，比如改成了 2222，那么 SSH 地址要写成ssh://git@你的GitLab域名:2222/用户名/仓库名.git这种带端口的格式。在 SourceTree 里克隆这种仓库时，源 URL 要填完整，不能省略端口。同时~/.ssh/config里也要对应改一下：

Host gitlab-company HostName 你的GitLab域名 Port 2222 User git IdentityFile ~/.ssh/id_rsa_gitlab

改完之后，仓库地址可以使用git@gitlab-company:用户名/仓库名.git这种写法，SourceTree 里照样能识别。这个映射方式的好处是，如果公司换了 GitLab 服务器的 IP 或者端口，你只需要改一处 SSH config，不用去改每个仓库的 remote 地址。

另外要注意，SourceTree 添加账号时的“托管主机”校验，是针对官方 API 地址做的。自建 GitLab 如果 API 地址是内网专用的，SourceTree 在启动时可能会尝试访问公共网络判断主机类型。遇到这种情况，哪怕已经添加了账号，也建议直接把仓库克隆下来就好，账号面板里的验证不通过不一定影响实际 Git 操作，因为 Git 操作本身走的是 SSH 或 HTTPS 凭证，不依赖那个托管主机图标是否正常。

5. 多账号管理与问题排查

5.1 多账号并存时的身份切换

GitHub 和 GitLab 账号都已经配置好之后，很多人会遇到一个尴尬局面：推送代码时用的身份不对。比如默认的user.name和user.email全局配置写的是自己私人 GitHub 邮箱，推送到公司 GitLab 时，提交记录里的作者信息就变成了私人邮箱，这在需要严格的代码审计环境里是大忌。

解决思路是区分全局配置和仓库级配置。全局配置在~/.gitconfig里，命令是：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

但如果你要针对某个仓库覆盖，就在那个仓库目录下执行：

git config user.name "公司GitLab用户名" git config user.email "公司邮箱"

这样之后这个仓库的所有提交都会用公司身份。SourceTree 本身也支持在每个仓库的仓库设置里查看和修改本地配置，位置是“仓库 → 仓库设置 → 高级”，里面可以单独设置用户名和邮箱。这一点很实用，因为 SourceTree 提交时读的就是本地配置，改完立刻生效。

还有一个更深层的问题：多个 SSH 密钥并存时，怎么确保访问 GitHub 用 GitHub 对应的密钥、访问 GitLab 用 GitLab 对应的密钥。前面提到的~/.ssh/config就是答案。如果你不想搞复杂的配置文件，还有个简化的办法：把两个密钥都加入ssh-agent，然后让 SSH 依次尝试。命令是：

ssh-add ~/.ssh/id_rsa_github ssh-add ~/.ssh/id_rsa_gitlab

这种方式下，GitHub 连接会尝试第一个密钥，如果被拒绝再尝试第二个，成功后会缓存一段时间。但问题在于，平台收到不匹配的密钥时会直接拒绝，SSH 会继续尝试下一个，虽然最终能成功，但日志里会有一堆 Permission denied 记录，排查问题时容易误导。所以我还是推荐用~/.ssh/config做明确的映射，一劳永逸。

5.2 常见报错对照与解决

在实际配置过程中，我遇到过不少报错，这里整理成一张速查表，方便你直接对照排查。

这里面排名第一的真凶是 SSH 密钥没被 ssh-agent 加载。很多人配好了~/.ssh/config，也确认了公钥已经贴到平台，但 clone 时依然报 Permission denied，原因就是私钥虽然存在于磁盘，ssh-agent 却没有把它加进内存。在 Linux/macOS 下执行ssh-add，Windows 下则要确认 SourceTree 使用的 Git Bash 环境是否能正确读取~/.ssh目录。SourceTree 通常能自动调用本机的 ssh-agent，但如果你自定义了 Git 安装路径，可能会导致找不到 agent，这时需要在系统服务里确认 OpenSSH Authentication Agent 服务处于启动状态。

另一个容易踩的坑是 GitLab 的令牌权限范围。如果你只勾选了read_repository，克隆没问题，但推送时会报You are not allowed to push code to this project。很多人被这个报错误导，以为是令牌过期，实际就是缺了write_repository权限。重新去 GitLab 令牌页面勾选权限再生成即可。

5.3 实际操作中的心得与避坑

配置过程中我积累了几个经验，写在这里供你参考。

第一，在 SourceTree 里添加账号的顺序和命名会影响仓库克隆后的识别。我建议 GitHub 账号用你的 GitHub 用户名，GitLab 账号也用对应的 GitLab 用户名，不要两个账号都用一样的名字，更不要在账号列表里留一堆重复账号。SourceTree 认账号主要靠托管主机加用户名，重复会导致它搞不清该用哪个凭证。

第二，关于仓库地址的选择，我的一条经验是 GitHub 用 SSH、自建 GitLab 也用 SSH，唯独公共 GitLab 上一些开源项目的只读克隆可以用 HTTPS。为什么会这样区分？因为自建 GitLab 的 HTTPS 证书经常是内网签发或自签的，SourceTree 对这类证书的校验策略比较严格，而 SSH 方式完全绕开了证书问题，只认密钥。公共 GitLab 上你没有推送权限的开源项目，用 HTTPS 方式克隆不会被要求凭证，反而方便。

第三，不要忘记 SourceTree 内部的缓存问题。改完账号或者令牌后，如果发现推送仍然使用旧凭证，可以尝试在命令行执行一次git push，让 Git 重新触发认证，这会让 SourceTree 刷新缓存。如果还是不行，在 SourceTree 的“工具 → 选项 → 认证”里删除旧账号重新添加，基本能解决。

最后再分享一个扩展技巧：如果你除了 GitHub 和 GitLab，还有其他 Git 服务，比如 Gitea、Bitbucket，或者公司的私有代码托管平台，配置逻辑都是一样的。拿到该平台的 API 地址、SSH 地址、个人访问令牌这三样东西，无非就是在 SourceTree 里照葫芦画瓢。真正的核心在于 SSH 配置文件的映射关系和令牌权限的准确勾选，这两个地方不出错，多平台共存基本就稳了。

我用这套方法配置过好几次，从零开始到两个平台都能正常推送，完整流程大概二十分钟。第一次配置时最容易不耐烦的环节就是 SSH 密钥验证，别跳过那一步，它帮你省下的排查时间远比你花在它身上的多。