简介这份资源围绕 Gitee、GitHub 与 GitLab 三大主流代码托管平台展开面向刚接触 Git 版本控制、需要完成代码托管与团队协作的开发者与运维初学者。内容以实操命令为主线覆盖远端仓库新建、本地代码推送、克隆下载、SSH 免密 push 等常见场景帮助读者打通从本地仓库到远端平台的完整链路。资源包共 1 个 docx 文档压缩后约 5.29MB以图文笔记形式整理关键命令与执行结果便于对照练习与查阅。文档中给出了 git add、git commit、git remote add、git push、git clone 等命令的实际执行示例并详细记录了 ssh-keygen 生成密钥对、复制公钥到平台、验证免密登录的完整流程同时包含首次连接时的指纹确认提示方便读者理解常见报错与排错思路。目前已有 74 人学习适合作为 Git 入门与多平台托管操作的参考笔记。1. 三个代码托管平台到底该把代码放哪很多团队都经历过这个场景项目一开始代码放在 GitHub后来因为访问速度或者合规要求迁到 Gitee再后来公司内部又搭了一套 GitLab 做私有化部署。三个平台同时存在账号、SSH 密钥、CI 配置各管各的新人入职第一周光配环境就耗掉两天。Gitee、GitHub、GitLab 这三个工具本质上都是基于 Git 的代码托管服务但定位差异很大GitHub 是开源生态和全球协作的中心Gitee 在国内访问速度和合规适配上更顺手GitLab 则是目前企业私有化部署最主流的选择自带完整的 CI/CD 和权限体系。这篇文章不打算泛泛对比功能列表而是从实际落地角度把三个平台的选型逻辑、环境配置、代码迁移、日常协作和踩坑经验讲清楚。适合正在做技术选型的团队负责人也适合刚接触多平台协作的开发者。2. 选型之前先搞清楚三个平台的定位差异在哪2.1 从访问速度、合规和生态三个维度拆解选平台这件事最怕的就是只看功能对比表。功能表上三家都支持 Git 仓库、Issue、Pull Request、CI/CD看起来差不多但实际用起来差别很大。GitHub 的核心优势在于开源生态。全球绝大多数知名开源项目都托管在 GitHub 上如果你需要参与开源协作、提交 PR、使用 GitHub Actions 做自动化它是首选。但国内访问 GitHub 的体验一直不太稳定clone 大仓库时经常断连CI 跑起来也慢。常见的做法是在本地配置 Git 的代理或者用镜像站加速但这不是长久之计。Gitee 的定位很明确国内访问快合规性好。很多国内团队把 Gitee 作为主仓库尤其是需要做等保或者代码审计的项目。Gitee 也支持 Pages 静态托管、CI/CD叫 Gitee Go但生态和第三方集成远不如 GitHub 丰富。另外 Gitee 开源许可证的选择需要留意如果你要发布开源项目MIT、Apache 2.0、GPL 这些常见协议都支持但选之前最好确认一下项目依赖的兼容性。GitLab 的定位是企业级私有化。它可以部署在自己的服务器上代码不出内网权限体系细到每个分支的保护规则、每个用户的角色Guest、Reporter、Developer、Maintainer、Owner。GitLab CI 是目前最成熟的流水线工具之一配合 Runner 可以做到从代码提交到部署的全流程自动化。但代价是运维成本——你需要自己维护服务器、升级版本、处理安全漏洞。2.2 一张表看清选型决策点维度GitHubGiteeGitLab自建访问速度国内不稳定需加速快取决于服务器位置私有仓库免费额度无限有限制取决于自建资源CI/CDGitHub ActionsGitee GoGitLab CI最灵活权限粒度中等中等非常细运维成本无无高适合场景开源协作、国际项目国内团队、合规项目企业私有化、深度定制选型的核心判断逻辑是如果你的项目需要面向开源社区GitHub 绕不开如果团队全在国内且对访问速度敏感Gitee 更实际如果公司有私有化部署要求GitLab 是标准答案。很多团队的实际做法是混合使用——GitHub 做开源镜像Gitee 做国内主仓库GitLab 做内部 CI/CD。3. 从零配好三个平台的开发环境3.1 Git 安装与全局配置不管用哪个平台本地都得先装 Git。Windows 上直接去 Git 官网下载安装包安装时注意勾选“Add Git to PATH”macOS 用 Homebrew 装最省事Ubuntu/Debian 用 apt。# macOS 安装 Git brew install git # Ubuntu/Debian 安装 Git sudo apt update sudo apt install git -y # 验证安装 git --version装完之后第一件事是配置全局用户名和邮箱这个信息会出现在每次 commit 记录里git config --global user.name 你的名字 git config --global user.email 你的邮箱example.com # 查看当前配置 git config --list这里有个容易翻车的点如果你在 GitHub、Gitee、GitLab 用的邮箱不一样commit 记录里的作者信息会对不上。常见做法是每个仓库单独配置或者统一用一个邮箱。3.2 SSH 密钥生成与多平台配置三个平台都支持 SSH 认证但如果你用同一个密钥去配三个平台管理起来会混乱。推荐的做法是按平台生成不同的密钥对# 为 GitHub 生成密钥 ssh-keygen -t ed25519 -C githubexample.com -f ~/.ssh/id_ed25519_github # 为 Gitee 生成密钥 ssh-keygen -t ed25519 -C giteeexample.com -f ~/.ssh/id_ed25519_gitee # 为 GitLab 生成密钥 ssh-keygen -t ed25519 -C gitlabexample.com -f ~/.ssh/id_ed25519_gitlab生成之后需要在~/.ssh/config里配置不同平台的映射# ~/.ssh/config Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_gitlab然后把对应的公钥.pub文件内容分别粘贴到各平台的 SSH Key 设置页面。验证是否配通ssh -T gitgithub.com ssh -T gitgitee.com ssh -T gitgitlab.company.com如果返回欢迎信息就说明通了。如果报Permission denied (publickey)先检查ssh -v的调试输出大概率是密钥没加载或者 config 文件路径写错了。3.3 GitLab 私有化部署的最小步骤如果团队决定自建 GitLab用 Docker 部署是最快的方式# 拉取 GitLab CE 镜像 docker pull gitlab/gitlab-ce:latest # 启动容器 docker run -d \ --hostname gitlab.example.com \ --publish 443:443 --publish 80:80 --publish 2222:22 \ --name gitlab \ --restart always \ --volume /srv/gitlab/config:/etc/gitlab \ --volume /srv/gitlab/logs:/var/log/gitlab \ --volume /srv/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest启动后需要等几分钟初始化然后访问服务器 IP 设置 root 密码。这里有几个关键参数--hostname要写实际域名或 IP否则 clone 地址会不对2222:22是把容器的 SSH 端口映射到宿主机 2222避免和宿主机 SSH 冲突三个 volume 分别挂载配置、日志和数据升级时不会丢。如果 80 端口被占用了可以把--publish 80:80改成--publish 8080:80然后在 GitLab 配置里改 external_url。4. 代码迁移与日常协作的实操路径4.1 从 GitHub 迁移到 Gitee 或 GitLab迁移仓库最稳妥的方式是 bare clone 再 push# 克隆裸仓库包含所有分支和标签 git clone --bare gitgithub.com:user/repo.git # 进入裸仓库目录 cd repo.git # 推送到 Gitee git push --mirror gitgitee.com:user/repo.git # 或者推送到自建 GitLab git push --mirror gitgitlab.company.com:group/repo.git--mirror会把所有分支、标签、引用都推过去比普通的 push 完整。迁移完之后本地开发环境需要更新 remote 地址# 查看当前 remote git remote -v # 修改 remote 地址 git remote set-url origin gitgitee.com:user/repo.git如果仓库里有 Git LFS 大文件迁移前要先git lfs fetch --all迁移后git lfs push --all否则大文件会丢失。4.2 GitLab CI 最小可用配置GitLab CI 的核心是.gitlab-ci.yml文件放在仓库根目录就会自动生效。一个最小的 Node.js 项目流水线# .gitlab-ci.yml stages: - install - test - build # 缓存 node_modules 加速后续阶段 cache: key: ${CI_COMMIT_REF_SLUG} paths: - node_modules/ install_deps: stage: install image: node:18 script: - npm ci run_tests: stage: test image: node:18 script: - npm run test build_project: stage: build image: node:18 script: - npm run build artifacts: paths: - dist/ expire_in: 7 daysstages定义了流水线的阶段顺序每个 job 通过stage归属到对应阶段。cache用来缓存依赖目录避免每次都要重新安装。artifacts把构建产物保存下来后续可以下载或者部署。image指定 job 运行的 Docker 镜像GitLab Runner 会自动拉取。这里有个实际经验cache和artifacts的区别容易搞混。cache 是为了加速不保证一定存在artifacts 是为了传递产物保证在 job 之间可用。构建产物用 artifacts依赖缓存用 cache。4.3 分支合并与权限控制三个平台的分支合并逻辑基本一致但 GitLab 的权限控制最细。在 GitLab 里Developer 角色默认可以提交代码到非保护分支但不能直接 push 到 master。如果想让 Developer 也能合并到 master需要在 Settings → Repository → Protected Branches 里调整。常见的分支策略是master 只允许 Maintainer 合并develop 分支允许 Developer 推送feature 分支随便建。合并请求Merge Request走 Code Review 流程至少一个人 Approve 才能合并。GitHub 对应的是 Pull RequestGitee 叫 Pull Request逻辑一样。保护分支的配置在仓库 Settings → Branches 里。5. 避坑多平台协作中最容易翻车的几个地方5.1 SSH 认证失败但密钥明明配了现象ssh -T gitgithub.com返回Permission denied (publickey)但确认公钥已经加到平台上了。原因最常见的是 ssh-agent 没有加载密钥或者~/.ssh/config里的 IdentityFile 路径写错了。另一个可能是密钥权限不对SSH 要求私钥文件权限必须是 600。解决先ssh-add ~/.ssh/id_ed25519_github手动加载然后chmod 600 ~/.ssh/id_ed25519_github修正权限。如果还不行用ssh -vT gitgithub.com看详细日志找到具体是哪一步失败了。5.2 GitLab 升级后旧版本 API 不兼容现象IDEA 或者 VS Code 的 GitLab 插件登录时报login failed. gitlab versions older than 14.0 are not supported。原因插件版本更新后不再兼容旧版 GitLab API。GitLab 的 API 在 14.0 之后有较大变动很多第三方工具跟进了新 API 就放弃了旧版本支持。解决要么升级 GitLab 服务端到 14.0 以上要么降级插件版本。如果服务端不能动建议改用 Git 命令行操作不依赖插件。GitLab 个人访问令牌Personal Access Token可以在用户设置里生成用令牌代替密码做 HTTPS 认证。5.3 从 Gitee 拉取项目到 IDEA 后依赖下载失败现象项目 clone 下来了但 Maven 或 Gradle 依赖拉不下来报连接超时。原因很多项目的依赖仓库配置指向了国外的 Maven Central 或者 JCenter国内访问不稳定。这跟 Gitee 本身没关系是依赖源的问题。解决在 Maven 的settings.xml里配置国内镜像源或者 Gradle 的init.gradle里替换仓库地址。常见做法是用阿里云的 Maven 镜像。5.4 GitLab 容器启动后 502现象Docker 部署的 GitLab 启动后访问页面显示 502等很久也没恢复。原因GitLab 启动需要初始化数据库和各个组件内存不够是最常见的原因。GitLab CE 最低需要 4GB 内存推荐 8GB。如果服务器内存不足Puma 或 Sidekiq 进程起不来就会 502。解决先docker logs gitlab看日志确认是哪个组件挂了。如果是内存问题要么加内存要么在gitlab.rb里调低 worker 数量puma[worker_processes] 2sidekiq[concurrency] 10。改完gitlab-ctl reconfigure生效。5.5 迁移后 commit 历史丢失现象用git push而不是git push --mirror迁移仓库结果只推了当前分支其他分支和标签都没了。原因普通git push只推当前分支不会推所有分支和标签。--mirror才是完整镜像。解决重新用 bare clone --mirror推一次。如果已经推了一部分先git push --mirror --force覆盖。6. 多平台统一管理的进阶技巧当你同时维护 GitHub、Gitee、GitLab 三个平台的仓库时手动一个个操作效率很低。我自己的习惯是用一个 remote 配置多个 push 地址一次 push 同步到多个平台# 添加多个 push 地址 git remote set-url --add --push origin gitgithub.com:user/repo.git git remote set-url --add --push origin gitgitee.com:user/repo.git git remote set-url --add --push origin gitgitlab.company.com:group/repo.git # 查看配置结果 git remote -v # 一次 push 到所有平台 git push origin main这样配置之后git push会依次推送到三个平台。拉取还是从第一个地址拉推送会推到所有地址。适合做镜像同步的场景。另一个实用技巧是用 GitLab 的 CI 做自动镜像。在.gitlab-ci.yml里加一个 job每次 push 到 GitLab 后自动同步到 GitHub 和 Giteemirror_to_github: stage: deploy only: - main script: - git remote add github gitgithub.com:user/repo.git - git push github main --force这个 job 只在 main 分支触发用 force push 保证镜像仓库和主仓库一致。注意需要把 GitHub 的 SSH 私钥配置到 GitLab CI 的变量里Settings → CI/CD → Variables变量名设为SSH_PRIVATE_KEY然后在 job 里加载。验证镜像是否成功的方法很简单在 GitHub 上查看最新 commit 的 hash 是否和 GitLab 上一致。如果一致说明同步成功不一致就检查 CI job 的日志。还有一个容易忽略的点三个平台的默认分支名可能不一样。GitHub 现在默认是mainGitee 有些老仓库还是masterGitLab 自建的默认分支可以在项目设置里改。做镜像同步时一定要确认分支名对齐否则推了个空。我自己踩过最深的坑是在 GitLab CI 里做镜像时忘了配 SSH 密钥的 known_hosts导致每次 push 都卡在主机指纹确认。解决办法是在 CI 脚本里加一行ssh-keyscan github.com ~/.ssh/known_hosts把目标平台的主机指纹预先写入。这个细节看起来小但卡住的时候排查起来很费时间。多平台管理说到底就是两件事认证要分离同步要自动化。认证分离靠 SSH config 和不同的密钥对同步自动化靠 CI job 或者多 push 地址。把这两件事做好三个平台用起来就跟一个差不多。希望帮到你。本文还有配套的精品资源点击获取