简介：这份资源围绕 Gitee、GitHub 与 GitLab 三大主流代码托管平台展开，面向刚接触 Git 版本控制、需要完成代码托管与团队协作的开发者与运维初学者。内容以实操为主线，覆盖远端仓库新建、本地仓库推送、git clone 拉取、分支指定，以及基于 SSH 密钥对的免密 push 配置流程，帮助读者打通从本地提交到远端托管的完整链路。资源包共 1 个 docx 文档，约 5.29MB，以图文笔记形式整理命令与操作说明，便于边看边练、随时查阅。目前已有 74 人学习关注，适合作为 Git 入门与多平台托管对照的参考材料，也可用于排查推送失败、认证异常等常见问题，快速建立对代码托管工作流的整体认知。
1. 从一次「推不上去」的深夜排查说起：Gitee、GitHub、GitLab 到底怎么选
上周帮同事看一个推送失败的问题，现象很典型：git push卡在Writing objects之后报403，但git clone同一个仓库却一切正常。折腾半小时才定位到——他之前为了图省事，把远端地址从 SSH 换成了 HTTPS，而本地git config --global里缓存的是另一个账号的凭据。这类问题在 Gitee、GitHub、GitLab 三个平台之间来回切换时特别高频，因为它们的认证模型、默认分支名、私有仓库策略都不一样。
这份资源把三个主流代码托管平台放在一起讲，核心价值不是「教你注册账号」，而是把「本地仓库怎么和远端对上」「免密怎么配」「分支怎么合」这条链路走通。它适合两类人：一是刚接触 Git、需要把本地代码托管到远端的开发者；二是已经在用某个平台、但换平台或换认证方式时反复踩坑的熟手。下面我按「平台差异 → 本地到远端 → 免密与分支 → 避坑 → 进阶」的顺序拆开讲，每一步都落到能直接抄的命令上。
2. Gitee、GitHub、GitLab 的平台差异与选型：别等推不上去才后悔
2.1 三个平台的定位与私有仓库策略
选平台这件事，很多人是「别人用啥我用啥」，结果到了要建私有仓库时才发现要付费。先把三者的基本盘摆清楚：
| 平台 | 私有仓库 | 典型场景 | 认证方式 |
|---|---|---|---|
| Gitee | 免费版有数量限制，超出需付费 | 国内访问快，个人项目、教学演示 | HTTPS 账号密码 / SSH 公钥 |
| GitHub | 免费版私有仓库数量不限 | 开源生态最全，CI/CD 集成成熟 | HTTPS Token / SSH 公钥 |
| GitLab | 自建社区版功能完整，SaaS 版按席位 | 企业内网部署、私有 CI/CD | SSH 公钥 / 个人访问令牌 |
Gitee 的优势在于国内网络环境下clone和push的响应速度，适合做日常代码备份和课程作业托管。GitHub 的强项是生态，大量开源项目和 Actions 工作流都默认跑在上面。GitLab 则是企业自建的首选，尤其是需要把代码托管和 CI 流水线放在同一套系统里的团队。
提示：私有仓库的「免费」是有边界的。Gitee 免费版对私有仓库的成员数和仓库数有约束，GitHub 免费版私有仓库不限制数量但协作者席位有限制，GitLab 自建版则取决于你部署的版本和许可证。选之前先确认你的协作规模。
2.2 本地仓库初始化与远端关联的完整链路
不管选哪个平台，本地到远端的链路是一样的：初始化本地仓库 → 提交 → 关联远端 → 推送。以 Gitee 为例，完整走一遍：
# 1. 初始化本地仓库 git init GitTest cd GitTest # 2. 创建第一个文件并提交 vim hello.py # 写入 print("hello world") git add hello.py git commit -m "提交 hello.py" # 3. 关联远端仓库（先在 Gitee 网页端新建一个空仓库） git remote add origin https://gitee.com/gyl_er/test.git # 4. 推送到远端主干分支 git push -u origin master这里有几个参数值得说清楚。git remote add origin里的origin是远端的默认别名，你可以改成别的名字，但后续所有命令都要跟着改，所以一般不动它。git push -u origin master里的-u是--set-upstream的简写，作用是把本地master分支和远端origin/master绑定，绑定之后下次直接git push就行，不用再写后面那一串。master是主干分支名，GitHub 现在默认是main，如果你在 GitHub 上建仓库时选了main，这里就要改成git push -u origin main，写错了会报src refspec master does not match any。
2.3 从远端克隆到本地的两种方式
克隆是把远端仓库完整拉到本地，命令本身很简单：
# HTTPS 方式克隆 git clone https://gitee.com/gyl_er/testt.git # SSH 方式克隆（需要先配好公钥） git clone git@gitee.com:gyl_er/testt.gitHTTPS 方式第一次执行会要求输入远端平台的用户名和密码，之后凭据会被缓存（取决于系统的 credential helper 配置）。SSH 方式则依赖本地私钥和远端公钥的配对，配好之后完全免密。克隆默认会创建一个和仓库同名的目录，如果你想把内容放到指定目录，可以在地址后面加目录名，比如git clone https://gitee.com/gyl_er/testt.git myproject。
克隆完成后ls一下，能看到仓库里的文件已经全部落到本地。这时候git remote -v可以查看当前关联的远端地址，确认是 HTTPS 还是 SSH，这个习惯在排查推送问题时特别有用。
3. SSH 免密配置与分支操作：把「每次输密码」这件事彻底干掉
3.1 生成密钥对并配置到远端平台
免密 push 的本质是 SSH 免密登录：本地生成一对密钥，私钥自己留着，公钥交给远端平台。第一步是生成密钥对：
# 配置全局用户名和邮箱（提交记录里会显示这些信息） git config --global user.name "your_name" git config --global user.email "your_email@example.com" # 生成 RSA 密钥对，-C 后面跟的是注释，一般填邮箱 ssh-keygen -t rsa -C "your_email@example.com"执行ssh-keygen后会提示输入保存路径，直接回车用默认的/root/.ssh/id_rsa或~/.ssh/id_rsa。如果该路径已有文件，会问你是否覆盖，输入y。接着会问passphrase，直接回车两次留空，这样后续使用就不需要再输密码。生成完成后，私钥在id_rsa，公钥在id_rsa.pub。
第二步是把公钥内容复制出来：
cat ~/.ssh/id_rsa.pub输出的内容以ssh-rsa开头，以邮箱结尾，整行复制。然后到 Gitee 或 GitHub 的「设置 → SSH 公钥」页面，粘贴进去保存。GitLab 在「用户设置 → SSH Keys」里。
第三步是验证配置是否生效：
ssh -T git@gitee.com如果返回Hi xxx! You've successfully authenticated，说明公钥配置成功。这里有个细节：Gitee 返回的提示里会带一句does not provide shell access，这是正常的，不代表配置失败，只是平台不提供交互式 shell。
3.2 切换远端地址实现免密推送
公钥配好之后，还需要把远端的关联地址从 HTTPS 换成 SSH，否则推送时走的还是账号密码那条路。操作如下：
# 查看当前远端地址 git remote -v # 删除旧的 HTTPS 远端 git remote rm origin # 添加 SSH 远端 git remote add origin git@gitee.com:gyl_er/testt.git # 推送并绑定分支 git push -u origin master第一次用 SSH 地址克隆或推送时，会看到一段The authenticity of host 'gitee.com' can't be established的提示，问你是否继续连接。输入yes回车即可，之后这个主机指纹会被写入known_hosts，不再重复询问。这一步的ECDSA key fingerprint是平台的服务端指纹，确认地址无误后放心输入yes。
3.3 分支创建、切换与推送到指定分支
实际开发中很少直接在主分支上改代码，常见做法是拉一个开发分支：
# 同步远端最新代码 git pull # 创建并切换到 dev 分支 git branch dev git checkout dev # 或者用一条命令完成创建加切换 git checkout -b dev # 在 dev 分支上开发 echo "新功能" > new.py git add new.py git commit -m "增加了发红包功能" # 推送到远端 dev 分支 git push -u origin devgit branch dev只创建不切换，git checkout dev才切换过去，两步合起来就是git checkout -b dev。推送时git push -u origin dev会把本地dev和远端origin/dev绑定，输出里会显示Branch dev set up to track remote branch dev from origin，说明绑定成功。之后在这个分支上直接git push就会推到远端dev。
3.4 通过 Pull Request 合并分支
分支推上去之后，需要把dev的改动合回master。Gitee 和 GitHub 都提供 Pull Request（GitLab 叫 Merge Request）机制：
- 在仓库页面点击「Pull Requests」→「新建 Pull Request」
- 源分支选
dev，目标分支选master - 填写标题和说明，可以指定审查人员
- 确认变更文件无误后点击「创建」
- 进入 PR 详情页，点击「合并」完成分支同步
合并完成后，master分支就包含了dev上的改动。如果合并时提示冲突，说明两个分支改了同一处代码，需要先在本地解决冲突再推送。常见做法是本地git checkout master、git pull、git merge dev，手动解决冲突文件后提交，再推送到远端。
4. 避坑与排查：那些让你怀疑人生的报错
4.1 push 报 403 或认证失败
现象：git push时提示403 Forbidden或Authentication failed，但git clone正常。
原因：远端地址是 HTTPS，本地缓存的凭据是另一个账号的，或者 GitHub 已经不支持密码认证，必须用 Token。
解决：先git remote -v确认地址。如果是 HTTPS，要么换成 SSH 地址（git remote set-url origin git@...），要么清除凭据缓存后重新输入。GitHub 用户需要在设置里生成 Personal Access Token，用它代替密码。
4.2 SSH 验证报 Permission denied
现象：ssh -T git@gitee.com返回Permission denied (publickey)。
原因：公钥没有正确添加到平台，或者本地私钥和平台上的公钥不匹配，也可能是ssh-agent没有加载私钥。
解决：先cat ~/.ssh/id_rsa.pub确认公钥内容，和平台上粘贴的是否一致。然后ssh-add ~/.ssh/id_rsa把私钥加入 agent。如果还不行，用ssh -vT git@gitee.com看详细日志，重点看Offering public key那几行。
4.3 推送时提示分支不匹配
现象：git push -u origin master报src refspec master does not match any。
原因：本地分支名和远端默认分支名不一致。GitHub 现在默认main，本地如果还是master就会对不上。
解决：先git branch看本地分支名，再git branch -r看远端分支名。如果远端是main，把推送命令改成git push -u origin main，或者本地重命名分支git branch -m master main后再推。
4.4 克隆时卡住或速度极慢
现象：git clone大仓库时进度条长时间不动，或者Receiving objects卡在某个百分比。
原因：网络链路问题，或者仓库体积过大导致单次传输超时。
解决：可以先用git clone --depth 1只拉最近一次提交，减少传输量。如果只是某个平台慢，换另一个平台的镜像地址试试。企业内网环境可以配置 GitLab 自建实例，把仓库放在内网。
4.5 合并分支时冲突处理不当
现象：Pull Request 显示This branch has conflicts that must be resolved，无法自动合并。
原因：源分支和目标分支修改了同一文件的同一区域，Git 无法自动决定保留哪个。
解决：本地切到目标分支，git pull拉最新代码，然后git merge 源分支，手动编辑冲突文件（文件里会有<<<<<<<和>>>>>>>标记），保留需要的代码后git add再git commit，最后推送。处理完再回到平台刷新 PR 页面，冲突提示会消失。
5. 进阶技巧：用一条命令看清仓库状态，以及我踩过的那些坑
5.1 用 git remote -v 和 git branch -vv 快速定位问题
排查推送问题时，我习惯先跑这两条命令：
# 查看远端地址和别名 git remote -v # 查看本地分支与远端分支的追踪关系 git branch -vvgit remote -v会列出所有远端别名和对应的地址，一眼就能看出当前用的是 HTTPS 还是 SSH。git branch -vv会显示每个本地分支追踪的远端分支，以及本地是否领先或落后。比如输出里[origin/dev: ahead 2]表示本地dev比远端多两个提交还没推，[origin/master: behind 3]表示远端有 3 个提交本地还没拉。这两条命令配合使用，大部分「推不上去」和「拉不下来」的问题都能在 10 秒内定位方向。
5.2 多平台共存时的配置隔离
同时用 Gitee、GitHub、GitLab 的人会遇到一个问题：全局user.name和user.email只能配一套，但不同平台可能想用不同的身份。解决办法是在单个仓库里覆盖全局配置：
# 进入某个仓库后，单独配置这个仓库的用户信息 git config user.name "work_name" git config user.email "work_email@company.com" # 查看当前生效的配置 git config --listgit config不加--global时只对当前仓库生效，加了--global才是全局。这样你可以全局配个人邮箱，在公司的 GitLab 仓库里单独配工作邮箱，提交记录就不会串。
5.3 SSH 多密钥管理
如果你在 Gitee 和 GitHub 上用了不同的密钥对，需要在~/.ssh/config里做区分：
# ~/.ssh/config 文件内容 Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_rsa_gitee Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github这样ssh -T git@gitee.com会自动用id_rsa_gitee，ssh -T git@github.com用id_rsa_github，互不干扰。配置完之后用ssh -T分别验证两个平台，都返回成功就说明隔离生效了。
5.4 一个我反复踩过的坑
早期我图省事，所有平台都用同一个密钥对，结果有一次在 GitHub 上删了旧公钥重新生成，忘了同步更新 Gitee 上的公钥，导致 Gitee 推送一直报Permission denied。排查了半天才想起来是密钥换了但平台没更新。从那以后我每次重新生成密钥，都会强制走一遍ssh -T验证三个平台，确认每个都返回successfully authenticated才继续干活。这个习惯帮我省了不少深夜排查的时间。
希望这些内容帮到你，少走几个弯路。
本文还有配套的精品资源，点击获取
