Repo 命令手册

Repo 的使用形式如下：

repo <COMMAND> <OPTIONS>

可选元素显示在方括号[]里面。例如，许多命令接受的项目列表作为参数。您可以指定项目列表作为名称列表或本地源目录的路径列表：

repo sync [<PROJECT0> <PROJECT1> <PROJECTN>]
repo sync [</PATH/TO/PROJECT0> ... </PATH/TO/PROJECTN>]

帮助

一旦 Repo 被安装，你可以找到总结所有命令的最新的文档，运行：

repo help

在 Repo 目录中运行如下这个，你可以获得任何命令的信息：

repo help <COMMAND>

初始化

$ repo init -u <URL> [<OPTIONS>]

在当前目录下安装 Repo。这会产生一个 .repo/ 目录，目录包括装 Repo 源代码和标准 Android 清单文件的 Git 仓库。.repo/ 目录还包括 manifest.xml，是一个在 .repo/manifests/ 目录选择清单的符号链接。

选项：

-u：指定一个恢复清单仓库的地址（URL）。常见的清单可以在 https://android.googlesource.com/platform/manifest 找到。
-m：在仓库里选择一个清单文件。如果没有清单名称，那么默认是 default.xml。
-b：指定一个修正，例如，一个特殊的清单分支（manifest-branch）。

注意：所有剩余的 Repo 命令，在当前工作目录下必须是 .repo/ 的父目录或是一个父目录的子目录。

同步

repo sync [<PROJECT_LIST>]

下载新的更改，更新在你本地环境中的工作文件。如果你不带参数运行 repo sync，它将同步所有项目的文件。

当你运行 repo sync，将会发生：

如果项目从来没有被同步过，那么 repo sync 相当于 git clone。在远程仓库的所有分支都被复制到本地项目目录。
如果项目曾经已经被同步过，那么 repo sync 相当于：
```
  git remote update   
  git rebase origin/<BRANCH>
```

<BRANCH> 是本地项目目录中的当前检查的分支。如果本地分支不跟踪远程仓库的分支，那么没有同步发生的项目。

如果 git rebase 操作导致合并冲突，你将需要使用正规的 Git 命令（例如，git rebase ——continue）去解决这个冲突。

一个成功的 repo sync 之后，指定项目中的代码将和最新的代码留在远程仓库中。

选项：

-d：切换指定项目回到清单修正。如果该项目目前是一个主题分支那就有帮助，但清单修正是暂时需要。
-s：同步到一个已知的构建 manifest-server 在当前清单指定的元素。
-f：继续同步其他项目，即使有项目同步失败。

上传

repo upload [<PROJECT_LIST>]

在指定的项目中，Repo 把本地分支的更新比作远程分支在最后一次 Repo 同步。Repo 会提示你选择一个或更多尚未上传审查的分支。

你选择一个或更多分支时，选到的分支上所有的 commits 会通过 HTTPS 连接传送到 Gerrit。你将需要配置一个 HTTPS 密码去启用上传授权。查看密码生成器生成新的用户名/密码配对去使用　HTTPS。

当 Gerrit 在它的服务器接收到对象数据时，它会把每个 commit 转变成更改，所以审阅者可以单独的评论每条 commit。将几条 “checkpoint” commits 一起合并到一条单个的 commit 上，然后在你运行 repo upload 之前使用 git rebase -i 。

如果你不带参数运行 repo upload，它将搜索所有项目上传的更改。

在更改（changes）上传之后进行编辑，你应该使用一个类似 git rebase -i 或 git commit --amend 的工具去更新你的本地的 commits。你所有编辑完成之后：

确保更新的分支是当前已审查的分支。

在系列里的每个 commit 的括号内输入 Gerrit 改变 ID：

  # Replacing from branch foo 
  [ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...
  [ 2829 ] ec18b4ba Update proto client to support patch set replacments 
  # Insert change numbers in the brackets to add a new patch set.
  # To create a new change record, leave the brackets empty.

上传完成后，更改将会有一个额外的补丁集（Patch Set）。

差异

repo diff [<PROJECT_LIST>]

在 commit 和工作目录之间使用 git diff 显示明显差异的更改。

下载

repo download <TARGET> <CHANGE>

从审查系统下载指定的更改，然后使它在你的项目的本地工作目录中可用。

例如，下载 change 23823 到你的平台/框架/基本目录：

$ repo download platform/build 23823

一个 repo sync 应该可以有效地移除任何通过 repo download 恢复的 commit。或者，你可以检查远程分支；例如，git checkout m/master。

注意:当更改在 Gerrit 网络上可见时和 repo download 被所有用户找到时，期间，有一个轻微的镜像滞后，因为复制延迟存在于全世界所有的服务器。

forall

repo forall [<PROJECT_LIST>] -c <COMMAND>

在每个项目中被给予的 shell 命令。如下的附加环境变量是通过 repo forall 才变得有效的：

REPO_PROJECT 设置项目唯一的名称。
REPO_PATH 是相对于客户端 root 的路径。
REPO_REMOTE 是清单中远程系统的名称。
REPO_LREV 是清单中修订本的名字，翻译成一个本地跟踪分支。如果你需要通过清单修正去本地执行 git 命令的时候可以使用。
REPO_RREV 是清单中修订本的名字，正如在清单中所写的那样。

选项：

-c：执行命令和参数。命令是通过 /bin/sh 评估的并且后面的任何参数就如 shell 位置的参数通过。
-p：在指定命令的输出前显示项目标题。这是通过绑定管道到命令的stdin，stdout，和 sterr 流，并且用管道输送所有输出量到一个连续的流，显示在一个单一的页面调度会话中。
-v：显示命令写到 sterr 的信息。

删减

repo prune [<PROJECT_LIST>]

删减（删除）已经合并的标题。

开始

repo start <BRANCH_NAME> [<PROJECT_LIST>]

一个新分支的发展，从清单中指定的修正开始的。

<BRANCH_NAME> 参数应该提供一个更改的简短说明给你正在尝试建立的项目。如果你不知道，那就考虑使用默认名称。

<PROJECT_LIST> 指定将要参与这个主题分支的项目。

注意："." 是当前工作目录下的项目的一个方便的简写。

状态

repo status [<PROJECT_LIST>]

比较工作目录和暂存区（索引），和这个分支（HEAD）在每个项目指定的最近一次提交。为每个不同于这三个状态的文件展示一个摘要行。

运行 repo status ，查看当前分支的状态。状态信息将会在项目中列表出来。项目中的每个文件，两个字母的代码是经常被使用的：

在第一列中，大写字母表明了暂存区和最后一次提交状态的差异。

字母	含义	描述
-	无变化	在 HEAD 和在索引中是一样的
A	增加	不在 HEAD, 在索引
M	修改	在 HEAD, 在索引表示修改
D	删除	在 HEAD, 不在索引
R	重命名	不在 HEAD, 在索引中改变路径
C	复制	不在 HEAD, 在索引中复制另一份
T	改变模式	在 HEAD 和在索引中是一样的内容, 改变模式
U	拆分	HEAD 和索引之间有冲突; 要求解决

在第二列中，一个小写字母表明了工作目录和索引的差异。

字母	含义	描述
-	新建/未知	不在索引, 在工作目录
m	修改	在索引, 在工作目录, 修改
d	删除	在索引, 不在工作目录