4、内核源码管理：Git版本控制、分支切换、补丁管理、内核配置文件的保存与恢复

在RK3588的BSP开发中，内核源码管理是决定项目可持续性的基石。很多开发者在初期只关注如何修改代码、编译镜像，却忽略了源码的版本演进、分支策略和配置追踪。当项目进入多产品线并行、多客户定制或长期维护阶段时，缺乏规范的内核源码管理会导致“改了什么不知道、为什么改不知道、如何回退不知道”的困境。本章将围绕Git版本控制、分支切换、补丁管理以及内核配置文件的保存与恢复四个核心维度，结合RK3588平台的实际工程场景，讲解一套可落地的管理方法论。

上图展示了RK3588内核源码管理的核心链路。从上游Linux内核仓库获取Rockchip官方分支，在本地建立BSP主分支，再派生出功能开发分支。补丁管理作为代码变更的载体，在分支间传递；配置文件则独立于代码分支，通过规范化流程保存与恢复。整个体系的核心在于：代码变更（补丁）与构建配置（defconfig）分离管理，分支策略服务于产品生命周期。下面我们将逐一拆解每个环节的具体操作与工程实践。

4.1 Git版本控制：从克隆到标签的完整链路

4.1.1 核心原理：为什么RK3588必须用Git管理内核

RK3588的BSP内核并非纯粹的Linux主线代码，而是Rockchip在Linux内核基础上维护的一个长期支持（LTS）分支，包含大量芯片平台相关代码（如drivers/soc/rockchip/、arch/arm64/boot/dts/rockchip/等）。这些代码与上游Linux内核存在持续的双向同步需求：一方面要吸收上游的安全补丁和功能更新，另一方面要维护Rockchip特有的驱动和硬件支持。Git的分支模型和标签机制恰好满足这种“多基线、多分支、可追溯”的需求。

在RK3588项目中，Git版本控制的核心价值体现在三个层面：可追溯性（每次提交都能定位到具体的修改人和修改原因）、可回退性（任何时间点都能恢复到历史状态）、可协作性（多开发者在不同功能模块上并行开发而不互相干扰）。

4.1.2 操作流程：标准的内核仓库初始化与分支管理

在开始RK3588内核开发前，需要完成以下Git初始化操作：

# 1. 克隆Rockchip官方内核仓库（以Linux 5.10为例）
git clone https://github.com/rockchip-linux/kernel.git -b linux-5.10-rockchip
cd kernel

# 2. 查看远程分支和标签
git branch -r
git tag -l "rk3588*"

# 3. 创建本地BSP主分支（基于官方tag）
git checkout -b rk3588_bsp_v1.0 rk3588_android12

# 4. 创建功能开发分支
git checkout -b feature/camera_support

# 5. 提交代码变更
git add drivers/media/platform/rockchip/
git commit -s -m "media: rockchip: add RK3588 camera sensor support"

在分支管理策略上，建议采用“主分支稳定、功能分支活跃、发布分支冻结”的模式。主分支（如rk3588_bsp）始终保持可编译、可运行状态；功能分支用于开发新功能，开发完成后通过Pull Request或Merge Request合入主分支；发布分支（如release/v1.0）在发布前从主分支拉出，只接受bug修复，不接收新功能。

4.1.3 案例拆解：多产品线并行时的分支策略

假设某公司同时开发RK3588的AI边缘计算盒子和智能NVR两款产品。两款产品共用90%的内核代码，但在摄像头接口、显示输出、网络配置上有差异。如果直接在同一个分支上开发，会导致代码互相污染。正确的做法是：

这种策略下，公共代码的bug修复只需在main分支进行一次，两个产品分支通过git merge同步即可。避免了在多个分支上重复修改同一处代码的维护噩梦。

4.1.4 常见误区与复盘

很多开发者在管理RK3588内核时容易犯以下错误：一是提交信息不规范，只写“fix bug”或“update”，导致后期无法追溯修改原因；二是忽略标签管理，发布版本不打tag，导致无法快速定位线上版本的代码状态；三是大文件入库，将编译产物或中间文件提交到Git仓库，导致仓库体积膨胀。正确的做法是：提交信息遵循“模块: 简述”格式（如“drm: rockchip: fix vop2 display flicker”），每次发布打annotated tag，使用.gitignore排除编译产物。

4.2 分支切换与代码同步：工程实践中的关键操作

4.2.1 核心原理：分支切换的本质与风险

分支切换在Git中本质上是移动HEAD指针并更新工作目录文件。但在RK3588内核开发中，分支切换不仅仅是代码层面的操作，还涉及编译环境的联动。内核源码树中的arch/arm64/configs/、drivers/等目录会随分支变化，而编译产物（如.config、.o文件）如果不清理，会导致“脏编译”问题。

4.2.2 操作流程：安全的分支切换与同步步骤

# 1. 切换分支前，确保工作区干净
git status
git stash  # 如果有未提交的修改，先暂存

# 2. 切换到目标分支
git checkout product/nvr

# 3. 清理编译产物（重要！）
make distclean  # 或 rm -rf .config include/config include/generated

# 4. 重新配置并编译
make ARCH=arm64 rockchip_defconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc)

# 5. 如果是从远程同步代码
git fetch origin
git merge origin/rk3588_bsp_main

4.2.3 案例拆解：分支合并冲突处理

在将product/ai_box分支合并回rk3588_bsp_main时，经常遇到设备树文件（.dts）的冲突。例如，AI盒子在rk3588-evb.dtsi中修改了I2C节点，而NVR分支也修改了同一节点。解决冲突的步骤：

1. 执行git merge product/ai_box，Git会标记冲突文件
2. 打开冲突文件，查找<<<<<<<标记
3. 分析两个版本的修改意图，保留正确的部分
4. 删除冲突标记，保存文件
5. 执行git add arch/arm64/boot/dts/rockchip/rk3588-evb.dtsi
6. 执行git commit完成合并

4.2.4 常见误区与复盘

分支切换最常见的误区是切换后不清理编译产物。RK3588内核的.config文件与具体分支强相关，如果从AI盒子分支切换到NVR分支后直接编译，会沿用旧的.config，导致编译出的内核包含错误的驱动配置。另一个误区是长期不更新主分支，导致功能分支与主分支的差异越来越大，最终合并成本极高。建议至少每周从主分支同步一次到功能分支。

4.3 补丁管理：从生成到应用的标准流程

4.3.1 核心原理：补丁在内核开发中的角色

补丁（Patch）是内核社区和BSP开发中传递代码变更的标准形式。在RK3588开发中，补丁管理主要用于三个场景：一是将本地修改提交给上游或合作伙伴；二是将Rockchip的SDK补丁应用到干净的内核源码上；三是在不同分支间移植特定功能。补丁的本质是“代码变更的描述”，包含修改的文件、行号和具体内容。

4.3.2 操作流程：补丁的生成与应用

# 1. 生成补丁（基于最近3次提交）
git format-patch -3 -o patches/

# 2. 生成单个提交的补丁
git format-patch -1 HEAD -o patches/

# 3. 应用补丁（推荐使用git am保留提交信息）
git am patches/0001-*.patch

# 4. 如果补丁冲突，使用git apply尝试
git apply --check patches/0001-*.patch  # 检查是否能应用
git apply patches/0001-*.patch          # 应用但不保留提交信息

# 5. 查看已应用的补丁
git log --oneline --decorate

4.3.3 案例拆解：将RK3588补丁集应用到干净内核

假设需要将Rockchip提供的BSP补丁集（通常位于SDK的kernel-patches/目录）应用到Linux 5.10主线内核上。这些补丁通常按模块分类，如drm、mali、usb等。操作步骤：

1. 解压SDK，找到补丁目录kernel-patches/
2. 查看补丁的依赖顺序（通常文件名前缀有编号）
3. 按顺序应用补丁：git am kernel-patches/0001-*.patch kernel-patches/0002-*.patch
4. 如果某个补丁应用失败，使用git am --abort回退，手动解决冲突后git am --continue
5. 应用完成后，验证内核版本：make kernelversion

4.3.4 常见误区与复盘

补丁管理中最常见的错误是使用git diff直接生成补丁。git diff生成的补丁不包含提交信息，无法追溯修改原因。另一个误区是补丁顺序混乱，导致应用时依赖关系断裂。建议在补丁文件名中明确编号和功能描述，如0001-drm-rockchip-add-vop2-support.patch。此外，不要将配置文件修改（如defconfig）与代码修改混在同一个补丁中，应分开管理。

4.4 内核配置文件的保存与恢复

4.4.1 核心原理：为什么不能直接拷贝.config

RK3588内核的.config文件是编译时的核心配置，它决定了哪些驱动被编译、哪些功能被启用。但.config文件包含大量自动生成的配置项（如CONFIG_CC_VERSION_TEXT、CONFIG_KERNEL_GZIP等），这些配置项与当前编译环境强相关。直接拷贝.config到另一台机器或另一个分支，会导致配置不一致。正确的做法是使用savedefconfig生成最小化的defconfig文件，或者使用diffconfig生成配置差异。

4.4.2 操作流程：配置文件的规范化保存与恢复

# 1. 在修改配置前，先保存当前配置
make ARCH=arm64 savedefconfig
cp defconfig arch/arm64/configs/rk3588_custom_defconfig

# 2. 修改配置（使用menuconfig）
make ARCH=arm64 menuconfig

# 3. 生成新的最小化defconfig
make ARCH=arm64 savedefconfig
diff -u arch/arm64/configs/rockchip_defconfig defconfig > config_changes.diff

# 4. 恢复配置（从defconfig生成.config）
make ARCH=arm64 rk3588_custom_defconfig

# 5. 查看配置差异
scripts/diffconfig arch/arm64/configs/rockchip_defconfig .config

4.4.3 案例拆解：多产品配置管理

假设AI盒子和NVR产品使用同一份内核源码，但配置不同。AI盒子需要启用NPU驱动和PCIe，NVR需要启用SATA和RAID。管理方案：

在编译时，先加载公共配置，再叠加产品特定配置：

make ARCH=arm64 rk3588_common_defconfig
scripts/kconfig/merge_config.sh -m arch/arm64/configs/rk3588_ai_box_defconfig
make ARCH=arm64 savedefconfig
cp defconfig arch/arm64/configs/rk3588_ai_box_full_defconfig

4.4.4 常见误区与复盘

配置文件管理中最严重的错误是将.config文件提交到Git仓库。.config文件是编译产物，不同机器、不同时间生成的.config都可能不同，提交到Git会导致无意义的冲突。另一个误区是直接修改defconfig而不验证。修改defconfig后，必须执行make ARCH=arm64 defconfig重新生成.config，并编译验证。建议在CI流程中加入配置验证步骤，确保defconfig能正确生成可编译的.config。

总结本章内容，RK3588内核源码管理的核心在于建立一套“代码变更可追溯、配置修改可复现、分支策略可扩展”的工程体系。Git版本控制提供了代码演进的基础框架，分支切换保证了多产品并行开发的隔离性，补丁管理实现了代码变更的标准化传递，配置文件管理则确保了构建结果的可重复性。在实际项目中，这四者相互配合，共同支撑起一个稳定、高效、可持续的内核开发流程。