很多开发者在同时使用 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_emailexample.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 keyGitLab 的位置是 Preferences → SSH Keys。这一步做完SSH 身份这一层就打通了。2.3 验证 SSH 连通性登记完公钥后不要急着打开 SourceTree先用命令行验证一下连通性可以省去后面排查的时间。GitHub 和 GitLab 都是用 SSH 协议来握手验证命令分别是ssh -T gitgithub.com ssh -T gitgitlab.com如果密钥配置正确GitHub 会返回类似Hi username! Youve 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 gitgithub.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 会自动拼出gitgithub.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 就是gitgithub.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或gitgitlab.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改完之后仓库地址可以使用gitgitlab-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 常见报错对照与解决在实际配置过程中我遇到过不少报错这里整理成一张速查表方便你直接对照排查。报错信息或现象可能原因解决办法Permission denied (publickey)SSH 密钥未登记或未加载检查公钥是否已添加到平台检查ssh-agent是否加载了私钥Authentication failed频繁弹出HTTPS 缓存了旧密码删除系统凭据管理器中的旧记录改用令牌login failed. check api token or gitlab versionGitLab API 版本不匹配检查 API 地址是 v3 还是 v4手动指定Repository not found地址中用户名或仓库名拼写错误确认仓库可见性检查地址是否带全路径克隆时提示fatal: Could not read from remote repositoryRemote URL 填错或 SSH config 映射错误核对 remote 地址测试ssh -T连通性SourceTree 中账户图标显示断开平台访问令牌过期重新生成令牌并替换旧令牌这里面排名第一的真凶是 SSH 密钥没被 ssh-agent 加载。很多人配好了~/.ssh/config也确认了公钥已经贴到平台但 clone 时依然报 Permission denied原因就是私钥虽然存在于磁盘ssh-agent 却没有把它加进内存。在 Linux/macOS 下执行ssh-addWindows 下则要确认 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 密钥验证别跳过那一步它帮你省下的排查时间远比你花在它身上的多。