3. 源码获取与管理：官方SDK下载、Repo工具使用、Git分支管理策略
做嵌入式Linux开发，第一步就是拿到源码。这一步看似简单，但坑不少。我记得刚接触RK3568时，以为直接从网盘拉个zip包就完事了，结果编译到一半发现缺模块，版本还对不上，折腾了两天才搞明白。说白了，源码管理这件事，从一开始就得走对路。
3.1 官方SDK的获取方式
Rockchip官方维护了一套完整的SDK，放在 gitlab.com 上。这套SDK包含了U-Boot、Linux内核、Buildroot、Debian、Yocto等所有组件。你不需要一个个去下载，官方提供了一个 repo 工具来统一管理。
获取SDK的典型流程如下：
# 1. 安装repo工具
mkdir -p ~/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
export PATH=~/bin:$PATH
# 2. 创建工作目录
mkdir rk3568_sdk && cd rk3568_sdk
# 3. 初始化repo仓库
repo init -u https://gitlab.com/firefly-linux/manifests.git -b master -m rk3568_linux_release.xml
# 4. 同步全部源码
repo sync -c --no-tags -j4
注意： 国内网络环境下载GitLab仓库可能会很慢。我建议你配置代理，或者使用国内镜像源。我曾经在没配代理的情况下硬拉，结果拉了整整一天还没拉完，最后断掉了，气得我直接换了方案。
3.2 Repo工具的核心用法
Repo是Google为Android开发设计的工具，用来管理多Git仓库的项目。RK3568的SDK有上百个Git仓库，手动管理根本不现实。Repo帮你把这些仓库的清单、分支、版本都管起来。
我平时最常用的几个Repo命令：
| 命令 | 作用 | 我的使用场景 |
|---|---|---|
repo init |
初始化repo工作区，指定manifest文件 | 第一次拉SDK时必用 |
repo sync |
同步所有仓库到本地 | 每天上班第一件事就是跑一次 |
repo start |
在所有仓库中创建新分支 | 开始一个新功能时使用 |
repo status |
查看所有仓库的状态 | 检查哪些文件被改了 |
repo diff |
查看所有仓库的差异 | 提交前做代码审查 |
repo upload |
将修改推送到Gerrit审核 | 团队协作时提交代码 |
小技巧：
repo sync -c --no-tags -j4 中的 -c 表示只下载当前分支，--no-tags 跳过标签，-j4 用4个线程并行下载。如果你带宽够大，可以试试 -j8 甚至 -j16，速度会快很多。
3.3 Git分支管理策略
拿到源码后，怎么管理自己的修改？这是个大问题。RK3568的SDK本身有多个分支：master 是开发主线，rk3568-linux 是稳定版，还有各种 release-* 标签。你不能直接在官方分支上改，否则下次同步时你的修改会被覆盖。
我个人习惯用这套分支策略：
- 保持官方分支干净：永远不在
master或rk3568-linux上直接提交。 - 每个功能一个分支：比如
feature/audio-driver、feature/lcd-panel。 - 用
repo start创建分支：这样所有相关仓库都会同步创建同名分支。 - 定期 rebase 到官方主线：避免分支落后太多，合并时冲突爆炸。
举个例子，假设我要开发一个LCD驱动：
# 在所有仓库中创建 feature/lcd 分支
repo start feature/lcd --all
# 进入内核目录修改代码
cd kernel
# ... 修改驱动代码 ...
# 提交修改
git add .
git commit -m "drivers: video: add support for MIPI-DSI LCD panel"
# 回到SDK根目录，查看整体状态
repo status
核心原则： 官方分支只用来拉取更新，你的所有修改都放在自己的分支上。这样无论官方怎么变，你都能轻松合并。
3.4 知识结构图：源码获取与管理流程
下面这张图把整个流程串起来了。从下载工具到最终提交代码，每一步都有对应的操作。
3.5 避坑指南
做源码管理这几年，我踩过的坑不少。挑几个典型的说说：
- 不要用
git pull代替repo sync：repo sync会处理所有仓库的依赖关系，git pull只拉当前仓库。我曾经图省事，在kernel目录直接git pull，结果其他仓库版本对不上，编译报了一堆错。 - 同步前先
repo status：看看有没有未提交的修改。如果有，先提交或stash，否则同步时可能冲突。 - manifest文件别乱改：
.repo/manifests/下的XML文件定义了所有仓库的版本。除非你知道自己在做什么，否则别动它。 - 分支命名要有规律：我习惯用
feature/xxx、bugfix/xxx、experiment/xxx。这样一看分支名就知道是干什么的。
血的教训： 我曾经在
master 分支上直接改代码，然后 repo sync 时忘了stash，结果官方更新把我的修改全覆盖了。两天的工作量，说没就没。从那以后，我每次 repo sync 前都会先 repo status 检查一遍。
3.6 日常开发工作流
最后，我总结一下日常开发的标准流程。你照着这个做，基本不会出问题：
- 早上到公司：
repo sync拉取最新代码。 - 开始新功能：
repo start feature/xxx --all创建分支。 - 修改代码：在对应仓库里改，改完
git add+git commit。 - 测试验证：编译、烧录、跑测试。
- 提交代码：
repo upload推送到Gerrit审核，或者直接git push到自己的远程仓库。 - 合并到主线：审核通过后，合并到
master或rk3568-linux。
嗯，这套流程我用了好几年，从RK3288到RK3568，一直没变过。你刚开始可能会觉得麻烦，但习惯了就会发现，它帮你省掉了无数个「代码丢了」「版本对不上」的烦恼。