企业官网建设流程全解析

去年有位朋友带着团队做了一个开源组件库，上线第一周就把主仓库放在 GitHub，又顺手同步了一份镜像到 Gitee。本来以为万事大吉，结果一个月后问题逐个冒出来：GitHub Actions 免费额度先烧完，Gitee 镜像仓库又因为两边不同步被用户反馈了不一致，团队内部为评审流程还吵了一轮。最后整个仓库被迫迁移，重新配置分支保护、Webhook 和 CI 文件就花了两天。这趟折腾让我想清楚了一件事：Gitee、GitLab、GitHub 这三个平台，从来不是简单的"哪个更好"，而是"你到底处于什么场景、需要什么能力"的关系。这几年我在三个平台上都长期维护过项目，各自的坑和甜头都尝过。这篇文章就把三者的定位差异、功能边界、CI/CD 能力、团队适配场景和迁移成本一次讲透，给正在纠结如何选择的个人开发者、团队负责人一份可以直接对照的判断框架。

1. 先看"出身"：三个平台从来不是同一物种

要理解为什么这三个平台选起来这么纠结，必须先搞清楚它们各自从哪来、为什么存在。表面上都是"托管 git 仓库"的网站，底层逻辑却完全不同。拿咖啡来类比：有人做的是社区第三空间，有人做的是标准化连锁门店，有人做的是本地精品小店——商业模式决定了产品走向，代码托管平台也是同理。

1.1 GitHub：开源文化长出来的全球协作网络

GitHub 最核心的资产不是那堆服务器，而是全球最大的开发者社区以及由此产生的网络效应。你的项目放在 GitHub，意味着能被全世界开发者看到、Fork、提 Issue、发 Pull Request。在这里收获的远不止版本管理功能，还有陌生人之间的协作、代码评审和口碑传播。代码托管只是底座，真正值钱的是那套社交关系链：Star、Fork、Follow、Contribute、Discussion、Sponsor。

对开源项目来说，这种生态几乎是不可替代的。我自己维护过一个小工具，放在 GitHub 上一年时间收到了来自多个国家和地区的 PR 和 Issue，有的贡献者我从来没见过，但对方提交的代码质量相当高。这种全球协作带来的"意外的善意"，就是 GitHub 独有的护城河。如果你追求的是项目被尽可能多的人使用和参与，GitHub 基本是绕不开的第一选择。

1.2 GitLab：从替代品长成了 DevOps 全家桶

GitLab 最初给人的印象是"开源的 GitHub 替代品"，但后来它的演进路线完全不同。它没有停留在代码托管，而是把 CI/CD、容器镜像库、制品库、安全扫描、Kubernetes 集成全做进了同一个产品，还提供了很成熟的自托管方案，社区版免费。对"数据不能出内网"的企业来说，GitLab 是少数能让整个研发链路都跑在内网的平台之一。

GitLab 的另一大优势是"单仓库搞定全流程"。它的 CI 和仓库深度绑定，你可以在同一个 Merge Request 页面里看到代码变更、流水线结果、测试覆盖率、环境部署状态，这种一体化体验在复杂项目里非常舒服。举个例子，一次发版前，我能在 MR 详情里直接看到测试通过、制品构建完成、测试环境部署成功，再手动点一下"部署生产"，整个流程不需要跳出平台半步。

1.3 Gitee：服务中文开发者生态的国内平台

Gitee（码云）诞生的核心诉求很朴素：给中文开发者提供一个访问快、文档友好、社区交流无障碍的代码托管服务。如果你的用户和贡献者主要集中在国内，Gitee 提供的访问速度和中文支持就是实打实的优势。它对国内一些开发协作工具的集成也更紧密，这一点对很多国内团队是有实际价值的。

Gitee 还实际承担了一个角色：GitHub 项目的国内镜像站。很多知名开源项目都会同步一份到 Gitee，方便国内用户快速查看和下载。所以对国内开发者来说，Gitee 更像是一座连接桥梁，帮你把全球开源项目和本地开发者生态对接起来。先搞清楚每个平台的"出身"，选择时的困惑其实已经去掉一大半。接下来要做的，就是把自己的具体需求逐条放上去比对。

2. 日常开发流程里的真实差异：仓库、评审、权限

被问得最多的一句话就是"这几个平台功能差不多吧？"——真不是。先用一个表格把三个平台在常规维度上的差异摊开，再挑几个影响最大的细节展开讲。

2.1 代码评审流程：PR 和 MR 不只是叫法不同

先说我用得最多的代码评审。GitHub 的 Pull Request 流程大家都比较熟：建分支、提交、发起 PR、页面里逐行评论、等 CI 状态检查通过、最后 merge。整体简单直接，适合大多数开源项目和中小团队。

GitLab 的 Merge Request 则更"重"一些。它对审批规则的支持更细，可以做到指定角色、指定人数才能合并，还能把代码质量检查和安全扫描直接嵌进合并条件。对合规要求高的企业团队，这种设计非常关键。GitLab 的很多权限能力，本质上都是在回答"谁能在什么条件下动生产分支"这个问题。

Gitee 的 Pull Request 流程跟 GitHub 更接近，基础评审、CI 状态集成、合并保护都有。但高级评审规则和自定义能力相比 GitLab 弱一些，常规团队够用，复杂组织架构会有点不够。

实际操作中我发现一个容易被忽略的点：很多人选平台只看"支不支持 code review"，却忽略了团队能不能让评审规则真正落地。GitHub 的分支保护和 required reviews 对多数团队已经绰绰有余。如果你的团队连"每个 PR 必须两个人 approve"都做不到，换到审批规则更重的平台，流程也未必能被强制执行。工具只是辅助，流程文化才是根本。

2.2 权限模型：从"够用"到"精细"的差距

权限管理是选平台时容易栽跟头的地方。GitHub 的角色划分比较清晰：Read、Triage、Write、Maintain、Admin，大多数场景够用。但如果你想要"某个人只能在某个目录下提交"这种精细控制，GitHub 默认不直接支持，需要配合 CODEOWNERS 和分支保护规则来组合实现，理解成本和维护成本都不低。

GitLab 对组织和权限的建模更接近企业级：Group、Subgroup、Project 的多层结构，每层都能设独立成员和权限；角色分 Guest、Reporter、Developer、Maintainer、Owner；还支持项目级覆盖继承权限。这种设计对大型组织很友好，但对小团队来说，层级多了反而觉得繁琐。

Gitee 的权限模型和 GitHub 类似，以仓库为单位管理成员和角色，企业版会增强组织管理能力。小团队用起来没什么障碍。我的建议很直接：团队在 20 人以内、组织架构扁平，按 GitHub 或 Gitee 的习惯来就行，别过度设计；如果公司有多条业务线、多人共同维护同一仓库的不同模块，GitLab 的层级权限能省下大量组织管理成本。

2.3 协作延展能力：Issue、Wiki、看板与讨论

三个平台在基础协作上都有 Issue、PR、Wiki、里程碑、看板等功能，但体验差异要按使用场景来看：

• GitHub 的 Discussion 是运营开源社区很好用的功能，可以做 Q&A、公告、RFC 讨论，比 Issue 更适合发散型讨论。
• GitLab 的里程碑、迭代和 Epic 等规划追踪能力更系统化，适合按敏捷迭代来管理项目。
• Gitee 的基础功能齐全，用语习惯更贴近国内团队，看板和企业协作能力也在持续完善。

对大多数团队来说，这些差异不会成为决定性因素，但如果你有明确的项目排期流程，那迭代管理工具用起来顺不顺手就值得认真比一比。

3. CI/CD 和自动化能力：选错平台，天天手动打包

很多人在选平台时只盯着"放代码"，结果项目一跑起来才发现自动化才是刚需。代码检查、自动测试、自动打包、自动部署，这些能不能顺滑跑起来，直接决定团队日常效率。三个平台的 CI/CD 能力差距比想象中大。

3.1 GitHub Actions：生态无敌，开箱即用

GitHub Actions 最打动人的是生态。那个巨大的 Action 市场里，从"发布 npm 包""部署到云服务器"到"发消息通知"，基本能想到的都有现成 Action 可以引用，不用自己造轮子。配置文件是 YAML，放在.github/workflows/目录下，提交代码就能触发。一个 Node 项目的典型流水线长这样：

name: CI on: push: branches: [main] pull_request: jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npm test - run: npm run build

这基本是所有 CI 方案里上手门槛最低的一类了。对开源项目，GitHub 在公共仓库免费提供 Actions 分钟数，是很大的福利；私有仓库的免费额度会动态调整，团队大了以后可能需要付费，不过很多小团队在额度内就够用了。我建议从一开始就把引用的第三方 action 固定到明确的 tag 或 commit hash 上，而不是直接指向@main，否则上游一更新，流水线可能毫无征兆地挂掉。

3.2 GitLab CI：一个引擎搞定内网全链路

GitLab CI 深度集成在平台里，配置文件是仓库根目录的.gitlab-ci.yml。它的核心优势有两个。一是 Runner 可以非常方便地自托管，尤其适合需要访问内网资源（测试环境、数据库、私有制品库）的团队——Runner 直接跑在公司内网，整个构建部署链路都不用出边界。二是 Pipeline 编排能力很强，Stages、Rules、Artifacts、Environments、Manual jobs 这些机制都很成熟，复杂的发布流程可以在一个文件里表达清楚。

举个典型场景：一个应用要经过"单元测试 -> 构建镜像 -> 推送制品库 -> 部署测试环境 -> 人工确认 -> 部署生产环境"这六步，GitLab CI 用 stages 加when: manual就能很自然地表达。GitHub Actions 也能做同样的事，但判断条件和 job 依赖的组织需要花更多心思。

如果公司已经决定"所有数据不出内网"，GitLab CE 自托管基本是当前最主流、最成熟的选项：装一台服务器，部署一个 Runner，研发团队就能用上接近 GitHub 的协作体验，同时拥有完整的内网 DevOps 链路。成本比商业 SaaS 低得多，前提是你有人力去维护。

3.3 Gitee Go：够用，但生态还在成长期

Gitee 也提供了 CI/CD 服务，叫 Gitee Go，通过在仓库里配置流水线实现自动化构建、测试和部署。它对 Gitee 仓库集成很自然，国内开发者访问快，操作习惯贴近本土工具，npm 构建、Java/Maven 构建、Docker 镜像构建等场景都有现成模板。

平心而论，对比 GitHub Actions 的巨型生态和 GitLab CI 的深度编排能力，Gitee Go 还处于成长期：第三方扩展生态相对少，社区分享的现成流水线案例也不够丰富，复杂流程需要自己多摸索。如果你的 CI 需求就是"跑测试、打镜像、发个包"，它完全够用；如果发布流程很复杂或者要求极高可定制性，建议把 CI 放到 Jenkins、其他开源流水线工具或前两个平台上去。

3.4 几条 CI 选型心得

跑了很多年项目，CI/CD 方面我总结了几条经验，能在选平台阶段就帮你少走弯路：

1. 先列流程，再选平台。把你们从代码提交到上线的全过程写出来，每一步需要什么工具、什么权限、谁来确认，再对照平台能力。最怕流程没想清楚就选平台，后面反复改配置。
2. 小团队不要优先自己搭建 CI。搭建 CI 本身不难，维护才是成本。没有专职运维人力时，优先用托管平台自带的 CI，把精力放在业务上。
3. 固定依赖版本。不管是 Actions 的第三方 action 还是 GitLab Runner 的镜像标签，全部锁定版本。这是我踩过坑以后养成的习惯。
4. 把 CI 配置纳入代码评审。流水线配置文件和代码一样要过评审，改 CI 也走 MR/PR，别让自动化体系在没人注意的时候慢慢"变胖"。

4. 按团队场景对号入座：开源、企业、初创团队

功能聊完，回到最实际的问题：我到底该选哪个？与其给一个万能答案，不如把你可能的身份拆开来看。

4.1 开源项目维护者：主 GitHub，辅 Gitee 镜像

如果你的目标是做一个开源项目，希望被更多人看到和参与，GitHub 基本是不可绕过的选择。贡献者的习惯和生态都在 GitHub——项目放上去，你能触达的全球协作网络，是其他平台很难替代的。对于面向国内用户的开源项目，我更推荐"主仓库放 GitHub，镜像同步到 Gitee"的做法。国内用户可以更快下载 Release、提交 Issue，主仓库的 Star、PR 统计则留在 GitHub。具体同步手段后面会详细讲，维护成本其实很低。

如果项目受众主要是国内企业客户，完全不追求国际社区，那反过来也可以：主仓库放 Gitee，GitHub 放只读镜像。核心原则是明确"哪个平台是你的社区主场"，别把运营精力分散在多个平台上。

4.2 企业内网项目：GitLab 自托管几乎是标准答案

企业场景下，代码就是资产。很多公司对代码和数据的存放位置有硬性要求，GitLab 自托管在这方面的优势很明显：安装在自己的服务器上，数据、日志、备份全在自己手里；支持 LDAP 和 SSO 登录，可以对接公司统一身份体系；Runner 部署在内网，构建部署不经过外部网络；安全能力也能按需开启。

有人会拿"GitLab 自托管维护重"来说事，这确实存在。但如果企业刚需就是代码不出内网，GitLab 是投入产出比很高的方案。我见过比较成熟的团队做法是：运维把 GitLab 当基础服务管理，做好备份、升级、监控，研发团队日常只感知到"有一个好用的内网代码平台，CI 还能帮我自动发测试环境"。达到这个状态，平台选择就已经成功了。

4.3 初创团队：云平台免费版先跑起来

初创团队的诉求往往很明确：预算有限、人手紧张、想快速把产品做出来。这个阶段不建议自建任何东西，直接在托管平台上选一个最顺手的先用起来。如果团队协作全中文、多数成员习惯国内产品，Gitee 挺好；如果希望未来更容易融入国际社区，GitHub 更合适。

我倾向给初创团队的建议是：选使用人数最多、教程最丰富、生态最完备的那个。因为团队会有新成员加入，新人对哪个平台更熟、遇到问题时更容易搜到答案，这些都是隐性效率因素。从这个角度讲，GitHub 的生态优势最明显，除非你明确知道自己不需要它。

5. 隐性成本盘点：速度、规则、免费额度

选择平台时，大家往往只关注功能列表，忽略了一批藏在细节里的成本。这些成本不会写在宣传页上，但实际使用中非常影响体验。

5.1 访问速度是体验的第一道门槛

服务器部署位置决定了访问体验。三个平台里 Gitee 的服务器在国内，国内网络下访问速度最快，clone、push、打开页面都更顺手；GitHub 和 GitLab 云服务的主要节点部署在海外，国内网络环境下访问速度存在客观差异，这是所有跨地域服务的普遍情况，属于正常的网络条件事实。很多国内团队最终选择 Gitee，首要原因就是快。

这里想提醒的是：要把访问速度当成一个客观维度来评估。如果团队绝大部分成员都在国内、协作以国内网络为主，Gitee 或自建内网平台在体验上确实占优势；如果成员分布广、需要国际协作，GitHub 的全球节点优势又体现出来了。关键不是哪个快，而是你的协作者分布在哪里。

5.2 平台规则和可见性管理

三个平台的社区规则和项目可见性管理各不相同，选择之前一定要了解清楚。GitHub 对开源项目持开放态度，公共仓库能被搜索引擎和社区发现，非常适合需要传播的项目；Gitee 对项目管理和审核有自己的规则，开源项目的可见性尺度要在使用前确认，涉及特殊内容时要格外谨慎；GitLab 云版相对中性，而企业自托管后规则完全由自己定，反而是最可控的。

我这些年得出一条经验：不要把任何一个托管平台当成"永久保险箱"。平台的条款、规则、免费政策都可能调整，重要项目必须有本地备份和异地备份的习惯，这一条在后面"多平台共存"部分会再展开。

5.3 免费额度的变动风险

"免费"永远是最吸引人的词，但免费政策的变动是三个平台共同的现实。GitHub 对公共仓库免费开放，私有仓库和 Actions 分钟数有免费额度；GitLab 云版有免费层级限制，自托管 CE 版免费但只含核心功能；Gitee 也有自己的免费与付费边界，私有仓库和企业功能的政策会随商业策略调整。

成熟的团队会把平台成本直接放进预算，而不是当成"永久的免费福利"。更稳妥的做法是：在所有平台的使用中都预留退路——定期备份、多平台镜像能力、标准化的 git 操作习惯。这样即使某天某个平台的免费政策或服务条款发生大变化，团队也能无缝切换，不被平台绑架。

6. 迁移、镜像与多平台共存：别让仓库成为孤岛

不管你现在选了哪个平台，有一点值得提前想清楚：万一以后想换平台，或者想同时用多个平台，成本到底有多高？好消息是，git 本身就是分布式的，切换平台没有很多人想象的那么可怕。

6.1 最轻量的思路：git remote 改一改

git 的核心设计决定了换平台很轻量。本地仓库一直都在，推送只是把 commit 推到某个 remote，"迁移"本质上就是把 remote 地址换一下。最常见的操作长这样：

# 查看当前 remote git remote -v # 添加新平台的 remote git remote add new-origin https://新平台地址/组织名/仓库名.git # 推送到新平台，所有分支和标签一起过去 git push --mirror new-origin # 确定不用旧平台后，切换默认 remote git remote set-url origin https://新平台地址/组织名/仓库名.git

git push --mirror会把本地所有分支、标签一股脑推过去，提交历史完整保留。这种轻量方式的限制在于：Issue、PR/MR 历史、CI 配置、Webhook 这些平台层面数据搬不过去。所以"迁移仓库"和"迁移平台"是两件事，后者要复杂得多。

6.2 用官方导入工具做一次性搬家

如果确实要整体迁移，三个平台都提供导入能力。GitHub 创建仓库时可以选择 import；GitLab 的项目创建流程里有 Import project 选项，支持从 GitHub、Gitee 等多种来源导入；Gitee 也支持从 GitHub、GitLab 导入仓库。这些工具一般能把代码和部分元数据带过来。

一次性导入之后，记得重新配置分支保护、评审规则、Webhook、CI/CD 和通知设置。这些配置不会自动跟过来。我见过太多团队"仓库搬过去了，但分支保护忘了配"，结果有人在主干上直接乱推。换平台后的第一件事，就是把旧平台的保护规则在新平台上一一条重建。

6.3 镜像同步：一套仓库，多个入口

比"迁移"更常用的思路是"镜像同步"。前面提到的开源项目"GitHub 主仓 + Gitee 镜像"，有两种常见实现方式。

一是利用 Gitee 自带的"从 GitHub 同步"功能。在 Gitee 创建仓库时直接导入 GitHub 仓库，之后可以手动触发，也可以定期自动同步。对国内开源项目来说，这个功能几乎零维护成本，非常实用。

二是用 CI 流水线做推送镜像。在 GitHub Actions 里配置一个定时或触发任务，把仓库推到 Gitee 或 GitLab 的镜像仓库：

name: Mirror to Gitee on: push: branches: [main] jobs: mirror: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Push mirror env: GITEE_TOKEN: ${{ secrets.GITEE_TOKEN }} run: | git remote add gitee https://${{ secrets.GITEE_USERNAME }}:$GITEE_TOKEN@gitee.com/你的组织/仓库名.git git push --mirror gitee

把 GITEE_TOKEN 配置成仓库的 secret 即可，逻辑换成 GitLab 或其他平台也通用。这里有个很容易踩的坑：常规 checkout 之后直接git push默认只推当前分支，镜像仓库会缺其他分支和标签。我第一次配置时就因为图省事，发现镜像仓库只有 main 一条分支，其他 feature 分支全不见了。所以镜像推送命令一定要写成完整的git push --mirror，或者先处理好远端 refs。

6.4 多平台共存的团队规范

如果团队同时用多个平台，一定要定几条简单规范防止混乱：

• 明确唯一的事实源（source of truth），其他平台只能从主仓库同步，不要两边同时直接写。
• 所有评审在主平台发起和完成，文档里写清楚紧急情况下也不要在镜像仓库直接改代码。
• 定期验证备份和镜像的可用性，不要等真丢了数据才发现备份是坏的。

我吃过这个亏：团队两个平台同步没定规范，结果有人在镜像仓库上直接改代码，下回同步时冲突一大堆，最后花了一整天才理清楚。定规范比事后救火省心太多。

7. 我最后给出的决策清单

说了这么多，最后直接给一份可以对照执行的决策清单。不需要全部满足，只要你的答案里哪一类占多数，基本就知道该往哪个方向走了。

如果把所有问题都看完还是拿不定主意，我的建议是先用托管平台免费版跑一个真实小项目体验两周：把代码推上去，配一次分支保护，跑一次 CI，模拟一个 PR 评审流程。真实感受比看一百篇对比文章都管用。

最后说一句个人体会：不要神化任何一个平台，也不要被"大家都用所以我也用"绑架。git 是分布式的，你的代码不该被平台锁死。用一个云平台做主战场，定期备份，必要时配一个镜像仓库，这套组合能应对绝大多数团队未来三五年的需求变化。上面这些经验都是我踩过坑换来的，希望帮你少走几步弯路。