SDK中repo,git 笔记

发表于 更新于 分类于 ， ，

Repo+Git嵌入式SDK开发核心笔记

适用场景：RK3588 / Linux / Android 嵌入式 SDK 版本管理与开发

一、核心概念（灵魂）

1. Manifest 仓库

  • 路径：.repo/manifests/

  • 定位：整个 SDK 的版本总控制器、版本清单

  • 作用：通过 XML 文件定义：

  • 每个子仓库（kernel、u-boot、device 等）

  • 来自哪个远程

  • 使用哪个分支 /commit

本质：manifest 分支 = 整套 SDK 的版本号

远程分支：厂商发布的稳定、可编译、官方版本

本地分支：你本地选中的版本入口

2. Repo 工具

  • 管理上百个 Git 子仓库的批量工具

  • 不编写业务代码，只负责版本对齐

  • 所有子仓库的版本，完全由 manifest 决定

3. repo sync -c

  • 作用：严格按照 manifest 清单，强制同步所有子仓库到官方指定版本

  • 执行流程：

  • 先同步 .repo/manifests/ 自身到最新

  • 读取当前分支下的 XML 配置

  • 批量 checkout 所有子仓库到对应版本

  • 结果：子仓库变为 (no branch) 游离状态（正常）

二、分支结构与关系

1. Manifest 分支（版本入口）

  • 远程分支：origin/linux → 官方稳定版本

  • 本地分支：

  • default：跟踪 origin/linux，推荐使用、安全稳定

  • linux：本地分支，若上游配置错误会导致同步失败

铁律：

  • 切换 manifest 分支 = 切换整套 SDK 版本

  • manifest 分支必须正确跟踪远程官方分支

2. 子仓库分支（开发使用）

  • 如 kernel-5.10、u-boot 内部分支

  • repo sync 完全不看子仓库的本地分支

  • 子仓库会被 XML 配置强制覆盖版本

三、Git 核心命令（必背）

1. git fetch

  • 作用：仅下载远程最新提交到本地缓存

  • 特点：

  • 不修改本地代码

  • 不合并、不覆盖、不切换分支

生成：origin/linux（远程分支在本地的只读镜像）

2. git rebase 【SDK 开发核心】

  • 定义：变基 = 换底座

  • 逻辑：

  • 把本地提交从「旧基线」拆下

  • 重新嫁接到「最新官方基线」之上

优点：

  • 历史线性干净

  • 无多余合并提交

  • 你的代码永远基于最新官方版本

禁忌：SDK 基线更新只用 rebase，不用 merge

3. git pull

  • = git fetch + git merge

  • 不推荐在嵌入式 SDK 中使用

  • 会产生网状历史，难以维护、排查问题

四、高频疑问与真相（避坑必备）

1. 两个分支提交一样，为什么一个能 sync 一个报错？

  • 提交一样 = 代码 / XML 文件完全一致

  • 差异点：分支上游跟踪配置（upstream）

  • repo sync 会先同步 manifest 自身

  • 若上游指向不存在的分支（如 master），直接报错

2. repo sync 到底以什么为准？

  • .repo/manifests 以 当前分支为准

  • 不以子仓库当前分支为准

  • 子仓库会被强制覆盖为 XML 中的版本

3. 为什么 repo sync 后是 (no branch)？

  • 因为 repo 直接切到一个 commit 哈希

  • 不是切到本地分支

  • 属于正常、标准、预期状态

4. default 分支是什么？

  • 本地分支，跟踪远程官方 origin/linux

  • 官方版本在本地的镜像

  • 永远不要在 default 上开发写代码

5. manifests 目录的版本管理逻辑（核心疑问）

  • 核心原则：manifest 仓库的 远程分支 = 官方 SDK 版本，但并非“一个改进一个新分支”，而是分「主版本分支」和「迭代更新」两种逻辑

  • 版本管理方式（官方常用）：

    • ① 主版本分支（长期存在）：比如 origin/linux（对应 SDK 主线版本）、origin/linux-5.10（对应 5.10 内核的稳定主线），这类分支会长期维护，用于承接日常小改进、bug 修复

    • ② 里程碑版本（标签 tag 辅助）：官方发布重大版本（如 V1.0、V2.0）时，不会新建分支，而是在主分支（如 origin/linux）上打 tag（如 v1.0.0），标记该 commit 为“正式发布版本”，方便开发者回溯历史稳定版

    • ③ 特殊版本分支（按需新建）：仅当出现“分支并行开发”需求时（如同时维护旧版 SDK 和新版 SDK），才会新建远程分支，比如 origin/linux-legacy（旧版维护）、origin/linux-next（新版测试）

  • 官方新改进的推进逻辑：

    • 日常小改进、bug 修复、小版本迭代：不新建分支，直接在原有主分支（如 origin/linux）上提交更新，不断向前推进（commit 叠加）

    • 重大版本升级（如内核从 5.10 升级到 6.1）：通常会新建分支（如 origin/linux-6.1），作为新的主版本分支，原有分支（origin/linux-5.10）保留，仅做 bug 修复，不再推进新功能

    • 测试版、预览版：可能会新建临时分支（如 origin/linux-dev），测试稳定后，将代码合并到主分支，再删除临时分支

  • 对开发者的影响：

    • 跟踪主分支（如 origin/linux）：执行 git fetch + git rebase 就能同步到官方最新改进，不用切换分支

    • 需要固定版本：可以基于主分支的某个 tag（如 v1.0.0）新建本地分支，避免被官方更新覆盖

    • 切换版本：若官方新建了新版本分支（如 origin/linux-6.1），只需修改 manifest 分支的跟踪关系，或切换 manifest 到对应分支，再执行 repo sync -c 即可同步整套新版本 SDK

五、SDK 开发标准工作流（永不翻车）

1. 同步官方最新基线

# 切换到正确的 manifest 分支
cd .repo/manifests
git checkout default
git fetch origin
git rebase origin/linux

# 同步整套 SDK
cd ../..
.repo/repo/repo sync -c -j1

2. 创建自己的开发分支（安全隔离）

# 进入要开发的仓库
cd kernel-5.10
# 从官方基线新建开发分支
git checkout -b develop

3. 官方更新后，刷新你的代码

git fetch origin
git rebase origin/linux

六、一句话终极总结

  • Manifest = 版本清单

  • Manifest 分支 = 整套 SDK 版本

  • repo sync = 按清单还原官方版本

  • git fetch = 下载远程最新状态

  • git rebase = 把你的代码搬家到最新官方基线

  • default 分支 = 本地官方镜像，只用于同步，不用于开发

  • manifests 版本管理 = 主分支承接日常迭代，tag 标记正式版本，特殊需求才新建分支

七、避坑铁律

  1. 不要随意修改 manifest 分支

  2. 不要在 default 分支上写业务代码

  3. repo sync 不会覆盖你的独立开发分支

  4. 上游配置错误是 manifest 同步失败的第一原因

  5. SDK 基线更新永远用 rebase，不用 merge

  6. 不要随意切换 manifest 远程分支，避免同步到非预期的 SDK 版本

  7. 固定版本时，用 tag 新建本地分支，不要直接依赖主分支

    （注：文档部分内容可能由 AI 生成）