Repo + Git + Gerrit 开发实战：从提交报错到多仓库协作，一文讲透

原创已于 2026-07-03 16:49:16 修改 · 516 阅读

本内容遵循CC 4.0 BY-SA版权协议

于 2026-07-03 16:35:45 首次发布

做安卓系统、嵌入式平台类大型项目开发的同学，几乎都会接触「Repo + Git + Gerrit」这套开发组合。和单仓库 Git 开发不同，大型项目会把代码拆分成上百个独立 Git 仓库，再通过 Repo 统一编排，最终通过 Gerrit 完成代码审核合入。
刚上手时很容易踩坑：提交被拒、分支不存在、邮箱校验失败、废弃的提交无法重新上传…… 本文把日常开发最常用的命令、高频报错、异常场景处理一次性讲透，兼顾基础原理与实战方案。

一、先理清三者的关系

很多新手的困惑，本质上是没分清三者的定位：
~Git：底层的版本控制系统，负责单个仓库的代码提交、回退、分支管理，是所有操作的基础。
~Repo：Google 推出的多 Git 仓库编排工具，本身不具备版本控制能力，底层完全调用 Git。它通过一份 manifest 清单文件，统一管理几十上百个 Git 仓库的地址、分支、路径，实现批量同步、批量提交。
~Gerrit：代码审核平台，基于 Git 实现，所有代码合入前必须先提交到 Gerrit 生成评审单，审核通过后才会合入正式分支。
简单说：Git 管单个仓库的代码版本，Repo 管一堆仓库的批量操作，Gerrit 管代码合入的审核流程。

二、开发环境前置配置

在开始代码提交前，需要先完成服务器与 Gerrit 账号的连通配置，这是所有操作的基础。
1.登录编译服务器
通过 SSH 登录开发编译服务器，执行后续所有代码操作。
2.Gerrit 平台账号配置
在终端执行命令查看本地公钥，将完整公钥内容添加到 Gerrit 账号的 SSH Keys 设置中

cat ~/.ssh/id_rsa.pub

3.连通性测试
配置完成后，执行 SSH 命令验证与 Gerrit 服务器的连接状态：

ssh -p

若返回 Gerrit 欢迎提示，说明身份认证成功，开发环境配置完成。

三、Git 基础原理与标准提交流程

3.1 Git 的三个核心区域
工作区：本地编辑器直接编辑的代码目录，是日常开发写代码的地方
暂存区：执行 git add 后文件的临时存放区，是提交前的缓冲地带
提交区：执行 git commit 后，代码正式存入本地版本库，生成永久提交记录
3.2 标准代码提交流程

git add . / git add filename -- 提交至暂存区

git commit -- 提交到提交区，并按规范编写commit

单仓库： git push origin HEAD:refs/for/目标分支名

多仓库： repo upload . --re=审核人账号

3.3 提交前撤销修改
代码修改后、还未执行 git add 时，如果想放弃本地改动、恢复原始状态，可以使用文件还原命令：git checkout 文件名
如果是git checkout 分支名，这个命令就是切换分支

补充：Git 2.23 版本之后，官方将这两个功能拆分为独立命令，降低使用歧义：
切换分支：git switch 分支名
还原文件：git restore 文件名

四、提交后常见场景处理方案

场景 1：提交后遇远程代码冲突
当你本地提交代码时，其他人已经向远程分支提交了新代码，就会出现提交冲突。此时推荐用 rebase 方式同步代码，保持提交历史线性干净。
操作步骤：
1.同步远程最新代码，并以 rebase 方式合并

repo sync -c

单仓库使用：git pull --rebase

手动解决代码冲突，完成 rebase 流程

git rebase --continue

按需更新提交信息

git commit --amend

最后重新提交即可
为什么推荐 --rebase 模式？
使用git pull --rebase 的时间线更干净，线性
远程分支：A-B-C
本地基于C，C-D-E
同事提交了C-F
远程变成了A-B-C-F
此时本地再基于C提交，log就会出现分叉，用了--rebase后，会把DE接到F后，log保持线性
场景 2：代码审核不通过，需要修改重提
Gerrit 上的评审单被打回、或标记为废弃（Abandon）后，不能直接在原提交上更新推送，需要回退提交、修改代码后重新生成提交。
操作步骤：
1.查看提交历史，定位两个关键提交

git log

SHA1：被打回 / 废弃的提交本身
SHA2：SHA1 的上一次提交（父提交）
日志中带有 origin/分支名标记的提交，就是你上次拉取远程代码的节点
2.回退提交，保留代码在工作区

git reset --mixed SHA2

执行后，原提交会被撤销，但所有代码改动保留在工作区，方便直接根据审核意见修改。

3.修改代码后，重新执行 add、commit、upload 流程，完成重新提交。

场景 3：提交基线过旧，合入冲突严重
如果提交间隔时间太久，本地代码基线和远程最新版本差异过大，直接修改容易引发大量冲突。可以先回到干净的基线，同步最新代码后，再把原有改动移植过去。
操作步骤：
1.记录被废弃提交的 SHA1，定位其父提交 SHA2
2.强制回退到父提交，清空所有改动

git reset --hard SHA2

3.拉取远程最新代码，更新本地基线
4.将原有代码改动移植到最新基线上

git cherry-pick SHA1

5.解决冲突后，重新生成提交并上传
git reset 三种模式的区别？
--soft，回退HEAD指针，相当于撤回git commit
--mixed，撤回git commit 和git add
--hard，工作区的代码改动都撤回了

五、临时暂存改动：git stash 用法

开发过程中经常会遇到中途打断的情况：比如功能写到一半需要切换分支、同步代码、修复紧急问题，此时代码还没写完，不适合生成正式提交，就可以用 git stash 临时收纳改动。
git stash save 把工作区和暂存区的改动都存为草稿
git stash list 查看有多少份草稿
git stash apply stash@{草稿编号} 把这份草稿拿回来
git stash pop stash@{草稿编号} 把这份草稿拿回来并删除
git stash drop stash@{草稿编号} 删除草稿
git stash clear 清空所有草稿