SalvageOfSDK
厂商以 .tar.gz 分发的大型嵌入式 SDK,没有版本历史、没有 repo 链路。把它恢复成由几十到上百个子仓库组成、可 repo sync 一键拉取、且编出的镜像能正常启动的 SDK —— 这件事我在两代 SOC 上各做了一轮。
- 第一次迭代（2025） — RV1126B / RK3568。原版 SDK,repo 清单完好。Python 脚本解析清单 + GitLab API 批量建仓,重点是把流程改造落到团队。
- 第二次迭代（2026） — RK3576。厂商深度定制,repo 链路已被销毁。Bash 工具链靠
find -name .git自动推导出 58 个仓库,重点是无清单前提下的取证式重建。
迭代对比
graph LR
A["2025 年<br>RV1126B 与 RK3568<br>Python 脚本<br>项目列表硬编码"] --> B["2026 年<br>RK3576<br>Bash 工具链<br>find .git 自动推导"]
B --> C["下一版<br>规则库化<br>判断可复用"]| 维度 | 2025 | 2026 | 下一版 |
|---|---|---|---|
| 语言 | Python | Bash | 待定 |
| 项目列表来源 | 手工解析清单后硬编码 | find -name .git 自动推导 | 同 2026 |
| 适用场景 | 清单完好的原版 SDK | 原版 + 清单被毁的定制 SDK | 同 2026 |
| 校验 | 覆盖率脚本 | 6 项自动断言 + 只读基线 | 同 2026 |
.gitignore 判断 | 逐个手工 | 逐个手工 | 规则库,按上游项目名索引 |
| 换 SOC 的成本 | 重抄项目列表 | 重新判断所有 .gitignore | 只判断没见过的项目 |
第一次迭代（2025）：从单体巨石到 repo 多仓库协同
该项目将一个以离线压缩包形式分发的、庞大的单体代码库，成功重构并迁移至内部 GitLab 服务器，建立了一套基于 Google `repo` 工具的模块化、多仓库（multi-repository）协同开发体系。
第二次迭代（2026）：把没有 repo 链路的厂商 SDK 恢复成 N 个 Git 子仓库
把一份被开发板厂商深度定制、repo 链路已损坏的 SDK 压缩包,恢复成可一键拉取、可正确编译、且镜像能正常运行的多仓库 SDK。