4、代码仓库管理：GitLab、GitHub、Gitee的选型对比与自建方案
说到代码仓库，这几乎是每个嵌入式团队绕不开的第一个基础设施。我见过不少团队，一开始随便选一个平台用着，等到CI/CD跑起来、权限管控出问题、或者代码被误删的时候，才后悔当初没好好选型。
今天我就把这三个主流平台——GitLab、GitHub、Gitee，掰开揉碎了讲清楚。顺便聊聊自建方案，毕竟嵌入式项目经常涉及核心固件，代码放哪、怎么放，真得慎重。
4.1 三巨头的基本定位
先给个直观的对比，你心里有个谱：
| 维度 | GitHub | GitLab | Gitee |
|---|---|---|---|
| 定位 | 全球最大的开源社区 | 企业级DevOps平台 | 国内开源与私有仓库 |
| 私有仓库 | 免费（有限协作人数） | 免费（不限） | 免费（不限） |
| CI/CD集成 | GitHub Actions（强） | 内置CI/CD（极强） | Gitee Go（中等） |
| 自建部署 | 不支持（仅SaaS） | 支持（社区版免费） | 支持（企业版收费） |
| 国内访问速度 | 慢（需代理） | 自建后取决于服务器 | 快 |
说白了，选哪个取决于你的团队规模、合规要求、以及CI/CD的深度需求。我个人习惯是：开源项目放GitHub，企业内部核心固件用自建GitLab，国内小团队图省事就用Gitee。
4.2 GitHub：开源首选，但嵌入式团队要注意什么
GitHub的生态确实好，Actions市场里有一大堆现成的嵌入式CI模板。比如编译ARM Cortex-M固件、跑QEMU模拟测试、甚至烧录到开发板，都能找到现成的workflow。
但我在项目中遇到过一个问题：嵌入式项目经常有大文件，比如编译器工具链、SDK包、或者编译产物。GitHub对单个文件有100MB的限制，而且仓库总大小建议不超过1GB。你想想看，一个完整的STM32CubeIDE工程加上SDK，很容易就超了。
所以我的建议是：GitHub适合放源码和配置文件，工具链和SDK用外部存储或镜像站。Actions里可以写一个step，先下载工具链再编译。
# .github/workflows/build.yml 片段
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: 下载ARM GCC工具链
run: |
wget -q https://developer.arm.com/.../gcc-arm-none-eabi.tar.bz2
tar -xjf gcc-arm-none-eabi.tar.bz2
echo "$PWD/gcc-arm-none-eabi/bin" >> $GITHUB_PATH
- name: 编译固件
run: make -j$(nproc)
4.3 GitLab：自建方案的王牌
如果你问我嵌入式团队最应该用什么，我会说自建GitLab。原因很简单：代码不出公司，CI/CD完全可控。
GitLab的CI/CD是原生集成的，不需要像GitHub那样依赖第三方服务。你只需要在仓库根目录放一个.gitlab-ci.yml，就能定义完整的流水线。而且它支持Runner部署在本地服务器上，编译嵌入式固件时可以直接挂载JTAG调试器，实现自动化烧录和测试。
我个人的经验： 在GitLab里配置一个“固件发布”流水线，每次打tag时自动编译、生成hex文件、然后通过SCP传到内网的固件服务器。测试人员直接下载烧录，省去了手动编译的麻烦。
自建GitLab的硬件要求其实不高：4核CPU、8GB内存、100GB SSD，就能支撑一个20人左右的团队。我建议用Docker部署，升级和维护都方便。
# docker-compose.yml 简化版
version: '3'
services:
gitlab:
image: gitlab/gitlab-ce:latest
hostname: gitlab.yourcompany.com
ports:
- "80:80"
- "443:443"
- "22:22"
volumes:
- ./config:/etc/gitlab
- ./logs:/var/log/gitlab
- ./data:/var/opt/gitlab
4.4 Gitee：国内团队的轻量选择
Gitee（码云）在国内的访问速度确实快，而且对中文支持好。如果你团队不大、没有严格的合规要求、也不想折腾自建，Gitee是个省心的选择。
但说实话，Gitee的CI/CD能力（Gitee Go）相比GitLab和GitHub还有差距。它的流水线配置不够灵活，支持的Runner类型也少。我在项目中试过用它跑嵌入式编译，结果发现免费版的构建时长有限，而且不能自定义Runner的硬件环境。
另外要注意一点：Gitee的企业版才支持自建部署，而且价格不便宜。如果你有自建需求，不如直接上GitLab社区版，功能更全还免费。
4.5 自建方案的核心考量
如果你决定自建，我建议你重点考虑这几个点：
- 存储与备份：嵌入式仓库经常有二进制文件，建议用对象存储（如MinIO）做Git LFS后端，每天自动备份到异地。
- 权限管控：不同芯片项目组之间要隔离，GitLab的Group + Subgroup + Project权限模型很合适。
- CI/CD Runner：嵌入式编译需要特定硬件（比如ARM交叉编译器），建议用Docker Runner + 自定义镜像，或者直接用Shell Runner挂载物理机。
- 网络与安全：内网部署的话，要配置好HTTPS证书和LDAP/OAuth认证。我见过团队直接用HTTP，结果被中间人攻击，代码泄露了。
4.6 选型决策树
最后给你一个简单的决策思路：
- 团队小于10人，项目开源或非核心 → GitHub（免费，生态好）
- 团队10-50人，需要私有部署和强CI/CD → 自建GitLab（社区版）
- 团队在国内，不想折腾服务器，合规要求低 → Gitee（企业版）
- 团队有核心固件，需要离线开发和审计 → 自建GitLab + 内网Runner
说白了，没有完美的平台，只有最适合你团队的选择。我个人的建议是：如果你有精力，优先自建GitLab。虽然初期搭建要花点时间，但后续的灵活性和可控性，绝对值得。
下一章我会讲怎么在GitLab里配置嵌入式CI/CD流水线，包括多架构编译、固件签名、以及自动化测试。到时候咱们再细聊。