3、源码获取与管理：Repo工具使用、manifest仓库管理、分支切换与代码同步策略
做开源鸿蒙开发，第一步就是搞定源码。这一步要是没走稳，后面全是坑。我见过不少新手，上来就 git clone 整个仓库，结果等了一下午还没下完——其实根本不用这么干。
今天咱们聊聊源码获取与管理的三板斧：Repo 工具、manifest 仓库、分支切换与同步策略。这三样东西，说白了就是一套组合拳，帮你把几百个 Git 仓库管得服服帖帖。
3.1 Repo 工具：多仓库管理的瑞士军刀
开源鸿蒙的源码，不是一个大仓库，而是拆成了几百个独立的小仓库。你想想看，要是每个都手动 git clone，那得累死。Repo 就是 Google 为了解决这个问题搞出来的工具，专门用来管理这种「多仓库项目」。
核心概念：Repo 本身是一个 Python 脚本，它不直接管理代码，而是通过读取 manifest 文件，帮你批量操作多个 Git 仓库。
3.1.1 安装 Repo
安装其实很简单，但要注意版本。我记得有一次在 Ubuntu 18.04 上装了个旧版 Repo，结果拉代码时各种报错。后来我学乖了，直接用官方推荐的方式：
# 创建 bin 目录并加入 PATH
mkdir -p ~/bin
export PATH=~/bin:$PATH
# 下载 Repo 工具
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
# 验证安装
repo --version小提示：建议把 export PATH=~/bin:$PATH 加到 ~/.bashrc 里，不然每次开终端都要重新设置。
3.1.2 Repo 的常用命令
Repo 的命令不多，但每个都很关键。我列几个最常用的：
| 命令 | 作用 | 使用频率 |
|---|---|---|
| repo init | 初始化 Repo 工作区，拉取 manifest 文件 | 极高（每个项目只做一次） |
| repo sync | 同步所有仓库的代码到最新 | 极高（每天用） |
| repo start | 基于当前分支创建本地开发分支 | 高（每次开发新功能） |
| repo upload | 将本地提交推送到 Gerrit 审核 | 中（提交代码时） |
| repo status | 查看所有仓库的状态 | 中（检查进度时） |
嗯，这里要注意：repo sync 默认会强制覆盖本地修改。如果你有未提交的代码，记得先 stash 或者提交，不然会被冲掉。我曾经就吃过这个亏，写了一半的代码全没了，从那以后我每次 sync 前都会先看一眼 status。
3.2 Manifest 仓库：源码的「地图」
Manifest 仓库，说白了就是一张清单。它告诉 Repo：你要拉哪些仓库、每个仓库在哪个地址、应该切换到哪个分支或 tag。
我个人习惯把 manifest 仓库比作「菜谱」。你照着菜谱买菜（拉代码），菜谱上写什么你就买什么，不会多也不会少。
3.2.1 Manifest 文件的结构
一个典型的 manifest 文件长这样：
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="openharmony"
fetch="https://gitee.com/openharmony/"
review="https://gitee.com/openharmony/" />
<default remote="openharmony"
revision="master"
sync-j="4" />
<project name="kernel_liteos_a" path="kernel/liteos_a" />
<project name="foundation_app" path="foundation/app" />
<project name="device_board_hihope" path="device/board/hihope" />
</manifest>这里有几个关键字段：
- remote：定义远程仓库的地址前缀
- default：设置全局默认值（比如默认分支、默认远程仓库）
- project：每个具体的仓库，name 是仓库名，path 是本地存放路径
避坑指南：我曾经遇到过一个情况——manifest 里某个仓库的 revision 写死了某个 tag，结果我 repo sync 了半天，发现代码根本不是最新的。后来排查才发现，是 manifest 没更新。所以，如果你发现拉下来的代码版本不对，先检查 manifest 文件。
3.2.2 如何管理自己的 Manifest
在实际项目中，我们经常需要维护自己的 manifest 仓库。比如团队内部有定制化的代码，或者需要锁定某个稳定版本。我的做法是：
- Fork 官方的 manifest 仓库到自己的 Git 账号下
- 创建一个新的分支，比如
team/v1.0 - 修改 default revision 指向我们团队的稳定分支
- 添加或替换某些 project 为我们内部的仓库地址
这样，团队成员只要执行 repo init -u 你的manifest地址 -b team/v1.0，就能拉取到统一的代码基线。
3.3 分支切换与代码同步策略
这部分是实战中的重头戏。你想想看，几百个仓库，每个都有自己的分支，怎么保证它们之间是兼容的？怎么在版本之间切换？
3.3.1 分支切换的正确姿势
很多人以为切换分支就是 git checkout，但在 Repo 管理下，事情没那么简单。正确的做法是：
# 1. 先查看当前 manifest 的分支
repo manifest
# 2. 重新 init 到目标分支
repo init -u https://gitee.com/openharmony/manifest.git -b OpenHarmony-3.2-Release
# 3. 同步代码
repo sync -c -j8-c 参数表示只同步当前分支，-j8 表示用 8 个线程并行下载。我个人习惯用 -j$(nproc)，让系统自动决定线程数。
重要提醒：切换分支前，一定要确保所有仓库的本地修改都已提交或 stash。否则 repo sync 可能会报错，甚至丢失修改。
3.3.2 代码同步策略：增量 vs 全量
代码同步有两种策略，我分别说说它们的适用场景：
| 策略 | 命令 | 适用场景 | 优缺点 |
|---|---|---|---|
| 增量同步 | repo sync | 日常开发，每天拉取最新代码 | 快，只下载差异部分；但可能产生冲突 |
| 全量同步 | repo sync --force-sync | 切换版本、修复仓库损坏 | 彻底，强制覆盖本地；但慢，需要重新下载 |
我建议日常开发用增量同步就够了。只有在以下情况才用全量：
- 仓库的 .git 目录损坏
- 从旧版本切换到新版本，且差异巨大
- 团队成员统一重置到某个基线
3.3.3 我的同步工作流
最后分享一下我个人的同步流程，供你参考：
- 每天早上到公司，先
repo status看看有没有未提交的修改 - 如果有，先 stash 或者提交
- 执行
repo sync -c -j8拉取最新代码 - 如果遇到冲突，用
repo diff查看具体差异 - 解决冲突后，用
repo start 新分支名 --all创建开发分支
这个流程我用了两年多，基本没出过问题。当然，偶尔也会遇到网络超时的情况——这时候别慌，重新执行一次 repo sync 就好，它会断点续传。
3.4 本章小结
源码获取与管理，说白了就是三件事：用 Repo 批量操作、用 Manifest 定义清单、用正确的策略同步代码。这三件事做好了，后面编译、调试才能顺风顺水。
我见过太多人在这上面栽跟头——要么是 repo init 时选错了 manifest 分支，要么是 repo sync 时忘了 stash 本地修改。嗯，这些坑我都踩过，所以希望你能少走弯路。
一句话总结：Repo 是手，Manifest 是眼，同步策略是脚。三者配合好了，源码管理就是小菜一碟。