2、版本控制系统选型与搭建：Git vs SVN，GitLab/GitHub/Gitee的选择，私有化部署方案
版本控制这件事，说白了就是嵌入式开发的「后悔药」和「时光机」。我见过太多团队，代码乱成一锅粥，最后连哪个版本能跑都不知道。嗯，咱们今天就把这事彻底聊透。
2.1 Git vs SVN：别纠结了，选Git
先说说我的个人习惯。十年前我刚入行时，公司用的是SVN。那时候觉得SVN挺好的，简单、直观，一个中央服务器，大家往上面提交代码。但后来我参与了一个分布式嵌入式项目，团队分散在三个城市，SVN的痛点就全暴露了。
SVN的问题在哪？
- 离线就废了：你想想看，嵌入式工程师经常要在客户现场、实验室、甚至出差路上写代码。SVN必须连上中央服务器才能提交、查看历史。没网？那就只能干瞪眼。
- 分支管理太笨重：SVN的分支本质上就是目录拷贝。我在项目中遇到过，有人创建了一个分支，结果整个仓库体积翻倍，服务器磁盘直接报警。
- 合并简直是噩梦：尤其是嵌入式项目里，驱动代码、BSP代码、应用代码混在一起，SVN的合并算法比较弱，经常出现冲突，而且解决起来很痛苦。
Git的优势在哪？
- 本地仓库，离线也能浪：Git是分布式的，每个人本地都有完整的历史记录。我在高铁上改代码、提交、看diff，完全不受网络影响。
- 分支轻量，随便玩：Git的分支只是一个指针，创建和切换几乎瞬间完成。我习惯每个特性、每个bug修复都开一个分支，最后再合并，干净利落。
- 合并算法强大：Git的三路合并算法比SVN聪明得多。当然，冲突还是会有，但至少Git给了你更多工具去处理。
核心结论：对于嵌入式软件，Git是唯一正确的选择。SVN已经属于上一个时代了。如果你还在用SVN，我建议你尽快迁移。
小提示：如果你团队里有人对Git不熟，别怕。Git的学习曲线确实比SVN陡一点，但一旦上手，没人会想回去。我建议先让团队用Git做个人项目，练熟了再上生产。
2.2 GitLab vs GitHub vs Gitee：怎么选？
选好了Git，接下来就是选托管平台。这三个我都深度用过，说说我的感受。
| 特性 | GitHub | GitLab | Gitee |
|---|---|---|---|
| 私有仓库 | 免费（有限制） | 免费（功能受限） | 免费（功能齐全） |
| CI/CD | GitHub Actions（强大） | 内置CI/CD（非常强大） | Gitee Go（基础够用） |
| 代码审查 | Pull Request（成熟） | Merge Request（成熟） | Pull Request（基础） |
| 私有化部署 | GitHub Enterprise（贵） | 社区版免费，企业版收费 | 企业版（收费） |
| 国内访问速度 | 慢（需要代理） | 取决于部署位置 | 快 |
| 社区生态 | 全球最大 | 中等 | 国内最大 |
我的建议是这样的：
- GitHub：如果你做开源项目，或者团队在国外，或者不介意网络问题，GitHub是首选。它的Actions生态太强了，几乎什么插件都有。
- GitLab：如果你需要私有化部署，GitLab社区版是免费的，而且功能非常全。我在一个军工项目里用过GitLab私有部署，完全满足合规要求。它的CI/CD是内置的，不用额外配置Jenkins，省了很多事。
- Gitee：如果你团队在国内，而且对访问速度有要求，Gitee是最佳选择。我曾经帮一个创业团队搭建CI，用Gitee + Gitee Go，从代码提交到固件生成，全程不到5分钟，体验很好。
注意：Gitee的免费私有仓库有5人限制，如果团队超过5人，需要付费。另外，Gitee的CI/CD功能相对基础，复杂流水线可能不太够用。
2.3 私有化部署方案：自己搭一个Git服务器
有些场景，比如军工、医疗、汽车电子，代码绝对不能出公司。这时候就需要私有化部署。我做过好几个私有部署项目，踩过不少坑，分享点经验。
方案一：GitLab社区版（推荐）
这是最成熟的方案。部署起来其实不难，我写个简单的步骤：
# 1. 安装依赖
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates postfix
# 2. 添加GitLab仓库并安装
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo EXTERNAL_URL="http://your-server-ip" apt-get install gitlab-ce
# 3. 配置并启动
sudo gitlab-ctl reconfigure嗯，就这么简单。装完之后，访问服务器IP就能看到GitLab界面了。第一次登录会让你设置root密码。
我的经验：GitLab比较吃内存，建议服务器至少4GB内存。如果团队超过50人，最好8GB以上。我曾经在一台2GB的机器上跑GitLab，结果动不动就502错误，后来加了内存才稳定。
方案二：Gitea（轻量级选择）
如果团队小，或者服务器资源有限，Gitea是个好选择。它用Go写的，非常轻量，1GB内存就能跑得很欢。部署也简单：
# 1. 下载二进制文件
wget -O gitea https://dl.gitea.io/gitea/1.21.0/gitea-1.21.0-linux-amd64
chmod +x gitea
# 2. 创建用户并运行
sudo adduser --system --group --disabled-password --shell /bin/bash --home /home/git git
sudo cp gitea /usr/local/bin/gitea
sudo -u git gitea webGitea的功能虽然不如GitLab全，但日常的代码托管、PR、CI/CD集成都够用了。我有个个人项目就用Gitea跑，已经稳定运行两年了。
方案三：Gerrit（代码审查专用）
如果你对代码审查有极致要求，比如每个提交都必须经过严格Review，Gerrit是专业选择。它本身就是为代码审查设计的。不过Gerrit的学习曲线比较陡，我建议非必要不选。
避坑指南：我曾经帮一个客户部署Gerrit，结果团队用了两周还搞不清楚怎么提交代码。后来还是换回了GitLab + Merge Request流程，大家才舒服了。所以，除非你的团队有严格的合规要求，否则别轻易上Gerrit。
2.4 嵌入式项目的特殊考量
最后，说几个嵌入式项目特有的点，你一定要注意：
- 大文件存储：嵌入式项目经常有编译器、SDK、固件镜像这些大文件。Git本身对大文件不友好，建议配合Git LFS（Large File Storage）使用。我在项目中遇到过，有人把整个编译器提交到Git仓库，结果仓库体积直接飙到10GB，克隆一次要半小时。
- 二进制文件管理：编译生成的.bin、.hex文件，建议不要提交到Git。这些文件每次编译都会变，而且没法做diff。正确的做法是用CI/CD自动生成，然后归档到制品仓库（比如Nexus、Artifactory）。
- 子模块管理：如果项目依赖多个仓库（比如BSP仓库、驱动仓库、应用仓库），可以用Git Submodule。但要注意，子模块的管理比较麻烦，我建议尽量用包管理器（比如West、Repo）来管理多仓库依赖。
重要提醒：千万不要把编译工具链、IDE安装包、第三方库的源码直接塞进Git仓库。这些应该通过包管理器或制品仓库来管理。否则，你的仓库会变得臃肿不堪，而且每次更新都痛苦。
好了，版本控制这块就聊这么多。下一章咱们讲CI/CD流水线的设计，那才是真正让嵌入式开发效率起飞的关键。