3、搭建Git服务器：Gitea/GitLab部署、SSH密钥配置、仓库权限管理、Webhook基础配置
好，咱们进入第三章。这一章要解决一个核心问题——代码放哪儿？
你想想看，嵌入式开发不像互联网项目，代码量可能不大，但硬件依赖、编译工具链、固件版本管理，这些乱七八糟的东西特别多。我见过不少团队，代码还在用U盘拷来拷去，或者扔在某个共享文件夹里。嗯，这种搞法，CI/CD根本无从谈起。
所以，咱们得先搭一个自己的Git服务器。我个人习惯用Gitea，轻量、省资源，跑在树莓派上都行。当然，如果你公司有现成的GitLab，那也行，我一起讲。
3.1 为什么嵌入式团队需要自建Git服务器？
有人会问：「GitHub不香吗？」香，但有几个现实问题：
- 代码安全：嵌入式固件往往涉及硬件核心算法，老板不放心放外网
- 网络限制：很多嵌入式开发环境是内网，甚至物理隔离
- 仓库大小：固件里经常要放二进制文件、SDK包，GitHub免费版有容量限制
- 权限粒度：硬件团队、驱动团队、应用团队，需要精细控制谁可以合并代码
我在一家做IoT设备的公司待过，当时就是GitHub私有仓库。结果有一次某个同事误操作，把包含WiFi密钥的配置文件给push上去了。虽然马上删了，但心里总不踏实。后来果断迁移到自建Gitea，所有流量不出内网，安心多了。
3.2 方案选择：Gitea vs GitLab
| 特性 | Gitea | GitLab |
|---|---|---|
| 资源占用 | 极低（128MB内存可跑） | 较高（建议4GB+内存） |
| 部署复杂度 | 单二进制文件，5分钟搞定 | 需要PostgreSQL、Redis等依赖 |
| 功能丰富度 | 够用，CI/CD需配合Jenkins | 自带CI/CD，功能全面 |
| 适合场景 | 小团队、资源受限环境 | 中大型团队、需要一体化DevOps |
我个人建议：如果你团队不超过20人，服务器配置也不高，直接上Gitea。省下来的内存给Jenkins或者编译服务器不香吗？
3.3 Gitea部署实战（Docker方式）
这是我最推荐的方式。干净、易维护、升级方便。
# 创建数据目录
mkdir -p /opt/gitea/data
mkdir -p /opt/gitea/config
# 启动容器
docker run -d \
--name=gitea \
-p 3000:3000 \
-p 22:22 \
-v /opt/gitea/data:/data \
-v /etc/timezone:/etc/timezone:ro \
-v /etc/localtime:/etc/localtime:ro \
gitea/gitea:latest启动后，浏览器访问 http://你的服务器IP:3000，进入安装页面。这里有几个关键配置：
- 数据库：小团队选SQLite就够了，别折腾MySQL
- SSH端口：如果宿主机22端口被占用，映射成其他端口，比如2222
- 域名：内网用IP就行，外网记得配域名和反向代理
3.4 GitLab部署（Docker方式，轻量版）
如果你确实需要GitLab，我建议用官方提供的docker-compose方式：
version: '3'
services:
gitlab:
image: 'gitlab/gitlab-ce:latest'
restart: always
hostname: 'gitlab.example.com'
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url 'http://gitlab.example.com'
gitlab_rails['gitlab_shell_ssh_port'] = 2222
ports:
- '80:80'
- '2222:22'
volumes:
- '/opt/gitlab/config:/etc/gitlab'
- '/opt/gitlab/logs:/var/log/gitlab'
- '/opt/gitlab/data:/var/opt/gitlab'3.5 SSH密钥配置——让开发机免密访问
这一步很关键。嵌入式开发经常要写脚本自动拉代码、打固件，总不能每次都输密码吧？
配置流程其实很简单：
- 开发机上生成密钥对：
ssh-keygen -t ed25519 -C "你的邮箱" - 把公钥（~/.ssh/id_ed25519.pub）内容复制出来
- 登录Gitea/GitLab，进入「设置」→「SSH密钥」→「添加密钥」
- 测试连接：
ssh -T git@你的服务器IP
这里我多说一句：密钥类型建议用ed25519，比RSA更安全，性能也更好。我见过不少老项目还在用1024位的RSA，说实话，那跟没锁门差不多。
避坑指南：我曾经遇到过一个问题——SSH连不上，报错「Permission denied」。查了半天，发现是Gitea容器里映射的SSH端口是2222，但开发机默认连22端口。解决方案：在~/.ssh/config里配置端口映射。
Host gitea-server
HostName 192.168.1.100
Port 2222
User git3.6 仓库权限管理——谁可以干什么
嵌入式项目通常分几个层级：
- 只读权限：测试人员、硬件工程师（只看代码，不改）
- 开发权限：普通开发人员（可以push到特性分支）
- 维护权限：团队负责人（可以合并到主分支）
- 管理员权限：你（啥都能干）
在Gitea里，进入「仓库设置」→「协作者」就可以添加用户并分配权限。GitLab更细，可以用「Group」来统一管理多个仓库的权限。
我个人习惯的做法是：
- 主分支（master/main）只允许Merge Request合并，禁止直接push
- 每个特性从主分支拉出，开发完提MR
- MR必须至少一个人Review才能合并
这样做的好处是——出了问题能追溯。我记得有一次，一个同事直接push到master，把整个固件编译搞崩了。从那以后，我就强制开启了「保护分支」功能。
3.7 Webhook基础配置——让代码变动自动触发CI
Webhook是CI/CD的「触发器」。说白了，就是当有人push代码、提MR时，Git服务器会发一个HTTP请求到你的CI系统（比如Jenkins），告诉它：「嘿，有代码更新了，快跑流水线！」
配置步骤（以Gitea + Jenkins为例）：
- 在Jenkins里创建一个Pipeline任务，记录下它的触发URL，比如：
http://jenkins-server:8080/project/固件编译/build - 在Gitea的仓库里，进入「设置」→「Webhooks」→「添加Webhook」
- 填写Jenkins的URL，选择触发事件（一般选「推送事件」和「拉取请求事件」）
- 保存，测试一下——随便push一个文件，看看Jenkins有没有自动触发
3.8 本章小结
好，这一章的内容就这些。总结一下：
- 小团队用Gitea，大团队用GitLab，别纠结
- SSH密钥配好，后面自动化脚本才跑得起来
- 权限管理要细，保护分支必须开
- Webhook是CI/CD的「导火索」，必须配
下一章，咱们开始搭建Jenkins，真正让流水线跑起来。到时候你会发现，前面这些准备工作有多重要。
嗯，今天就到这儿。有问题欢迎在评论区交流，或者来我公众号「蓝海资料掘金营」找我，微信deep3321。