EDA365电子论坛网
标题: Repo:Android 源码管理的利器--工作原理与常用命令全解析 [打印本页]
作者: 武汉万象奥科 时间: 2024-10-28 14:58
标题: Repo:Android 源码管理的利器--工作原理与常用命令全解析
本帖最后由 Heaven_1 于 2024-10-28 16:28 编辑
% M! F. M0 l. C2 M1 }/ {; t! p1 v6 O: Q1 P% |3 U2 P. r
1. 概要
- J4 Z/ k5 L+ y8 a9 M
repo是Android为了方便管理多个git库而开发的Python脚本。repo的出现，并非为了取代git，而是为了让Android开发者更为有效的利用git。
Android源码包含数百个git库，仅仅是下载这么多git库就是一项繁重的任务，所以在下载源码时，Android就引入了repo。 Android官方推荐下载repo的方法是通过Linux curl命令，下载完后，为repo脚本添加可执行权限：
- $ curlhttps://storage.googleapis.com/git-repo-downloads/repo > 1 A5 Y( [. e* a K( k: R
- ~/bin/repo
: k% ]% d) L0 G) ^6 ~ - $ chmod a+x~/bin/repo
由于国内Google访问受限，所以上述命令不一定能下载成功。其实，我们现在可以从很多第三方渠道找到repo脚本，只需要取下来，确保repo可以正确执行即可。
3 d. s5 @& i9 t* ?2 F: J
2. 工作原理
/ `* ?" x) u; q4 }
repo需要关注当前git库的数量、名称、路径等，有了这些基本信息，才能对这些git库进行操作。通过集中维护所有git库的清单，repo可以方便的从清单中获取git库的信息。 这份清单会随着版本演进升级而产生变化，同时也有一些本地的修改定制需求，所以，repo是通过一个git库来管理项目的清单文件的，这个git库名字叫manifests。
, B3 \' D" E( k/ c$ M9 a L当打开repo这个可执行的python脚本后，发现代码量并不大(不超过1000行)，难道仅这一个脚本就完成了AOSP数百个git库的管理吗？并非如此。 repo是一系列脚本的集合，这些脚本也是通过git库来维护的，这个git库名字叫repo。
% Y. ?1 ?1 n* ?' D! v8 v) [# R8 f
在客户端使用repo初始化一个项目时，就会从远程把manifests和repo这两个git库拷贝到本地，但这对于Android开发人员来说，又是近乎无形的(一般通过文件管理器，是无法看到这两个git库的)。 repo将自动化的管理信息都隐藏根目录的.repo子目录中。
- g. {/ Y7 [! P8 N+ f+ f2.1 项目清单库(.repo/manifests)
AOSP项目清单git库下，只有一个文件default.xml，是一个标准的XML，描述了当前repo管理的所有信息。
AOSP的default.xml的文件内容如下：
- <?xmlversion="1.0" encoding="UTF-8"?>3 ], M) v$ E( i! y8 v- L* a
- <manifest>
* M" Q5 B5 t1 W" C; ]. q4 I5 v - <remote name="aosp"2 T/ b0 \+ ]7 S& d% ~! ~6 [
- fetch=".."8 N; T$ L* s5 J9 s" w
- review="https://android-review.googlesource.com/" />, Y* X2 N5 O" ?4 E M! O7 a- g. ^
- <default revision="master"0 ^" U4 |) L& Y
- remote="aosp"
2 u2 r# X; r& e - sync-j="4" />! l4 o5 r, s# c9 r
- <project path="build"name="platform/build" groups="pdk,tradefed" >
" u$ v% T% ~$ i# k' @' P4 c) X - <copyfilesrc="core/root.mk" dest="Makefile" />
) u$ \+ N+ y2 p% b8 F& S - </project>
" m6 Y9 ~% ]* }& D2 p6 g* A: C4 z - <project path="abi/cpp"name="platform/abi/cpp" groups="pdk" />
9 n [( E% |& {& Y" B - <project path="art"name="platform/art" groups="pdk" />1 z& L1 H( @2 Q: j: R
- ...
; Y% _0 U, k+ Q$ J. }# B7 {7 Y: @; X - <projectpath="tools/studio/translation"name="platform/tools/studio/translation"groups="notdefault,tools" />4 h2 N3 X" Y& J7 P0 Q: b5 C2 T
- <project path="tools/swt"name="platform/tools/swt" groups="notdefault,tools" />4 L% b6 l. ]- [. n& P# m
- </manifest>
. ~: i1 ?- e% R% q" A# u- ：描述了远程仓库的基本信息。name描述的是一个远程仓库的名称，通常我们看到的命名是origin;fetch用作项目名称的前缘，在构造项目仓库远程地址时使用到;review描述的是用作code review的server地址
- ：default标签的定义的属性，将作为标签的默认属性，在标签中，也可以重写这些属性。属性revision表示当前的版本，也就是我们俗称的分支;属性remote描述的是默认使用的远程仓库名称，即标签中name的属性值;属性sync-j表示在同步远程代码时，并发的任务数量，配置高的机器可以将这个值调大
- ：每一个repo管理的git库，就是对应到一个标签，path描述的是项目相对于远程仓库URL的路径，同时将作为对应的git库在本地代码的路径; name用于定义项目名称，命名方式采用的是整个项目URL的相对地址。 譬如，AOSP项目的URL为https://android. googlesource.com/，命名为platform/build的git库，访问的URL就是https ://android.googlesource.com/platform/build
$ E. _- U( a7 q$ U
& U" ~7 S7 B3 j- T, Z D& b1 W1 t如果需要新增或替换一些git库，可以通过修改default.xml来实现，repo会根据配置信息，自动化管理。但直接对default.xml的定制，可能会导致下一次更新项目清单时，与远程default.xml发生冲突。 因此，repo提供了一个种更为灵活的定制方式local_manifests:所有的定制是遵循default.xml规范的，文件名可以自定义，譬如local_manifest.xml, another_local_manifest.xml等， 将定制的XML放在新建的.repo/local_manifests子目录即可。repo会遍历.repo/local_manifests目录下的所有*.xml文件，最终与default.xml合并成一个总的项目清单文件manifest.xml。
local_manifests的修改示例如下：
- $ ls.repo/local_manifests
: F$ l1 b+ p) Y% X8 N- l - local_manifest.xml
7 D; s, B6 T; r' j& [. E6 a - another_local_manifest.xml
/ n5 M c$ x, Z
M; }; c# W3 g& L- $ cat.repo/local_manifests/local_manifest.xml7 ]* y( ~) |5 F d( C3 \+ K
- <?xmlversion="1.0" encoding="UTF-8"?>
P9 Y# T/ v& a7 N# a( f - <manifest>
- R3 F" Y1 U& W) M0 ^ - <project path="manifest"name="tools/manifest" />' o2 l$ l( T; H5 c5 E1 d
- <projectpath="platform-manifest" name="platform/manifest" /> w B B! ]6 y6 M$ t `, ?: x1 p
- </manifest>
6 ^5 a8 y* t6 C+ F, h( N
, m5 d. p7 p$ F2.2 repo脚本库(.repo/repo)
repo对git命令进行了封装，提供了一套repo的命令集(包括init,sync等)，所有repo管理的自动化实现也都包含在这个git库中。 在第一次初始化的时候，repo会从远程把这个git库下载到本地。
s% M5 Y9 F) E' c; a3 h2.3 仓库目录和工作目录
仓库目录保存的是历史信息和修改记录，工作目录保存的是当前版本的信息。一般来说，一个项目的Git仓库目录（默认为.git目录）是位于工作目录下面的，但是Git支持将一个项目的Git仓库目录和工作目录分开来存放。 对于repo管理而言，既有分开存放，也有位于工作目录存放的:
- manifests： 仓库目录有两份拷贝，一份位于工作目录(.repo/manifests)的.git目录下，另一份独立存放于.repo/manifests.git
- repo：仓库目录位于工作目录(.repo/repo)的.git目录下
- project：所有被管理git库的仓库目录都是分开存放的，位于.repo/projects目录下。同时，也会保留工作目录的.git，但里面所有的文件都是到.repo的链接。这样，即做到了分开存放，也兼容了在工作目录下的所有git命令。
$ w( F$ f g5 D) N9 p. a
既然.repo目录下保存了项目的所有信息，所有要拷贝一个项目时，只是需要拷贝这个目录就可以了。repo支持从本地已有的.repo中恢复原有的项目。
, d V% h: p$ E4 b3 N
2.4 repo 目录结构分析
- .repo：
" W- G. S4 a$ V. Q
此为repo目录，可用于提取相应项目工作目录到外面的repo工作目录。
- .repo/manifests.git：6 S% {4 L% V; }
此为repo配置信息的git库，不同版本包含不同配置信息。每个repo项目初始化后也会有自己的git仓库的repo也会建立一个Git仓库，用来记录当前Android版本下各个子项目的Git仓库分别处于哪一个分支，这个仓库通常叫做：manifest仓库。
- .repo/manifests：: c+ o+ P" U( r' G7 ^' ^4 s/ Z. a
此为repo配置信息的工作目录（将配置信息的工作目录和相应的实际git目录分离管理，并且配置信息中的.git目录实际只是指向实际git库的软连接）。此目录中可能包含一个或多个xml文件描述的配置。每个xml文件是独立的一套配置，配置内容包括当前repo工作目录包含哪些git项目、所有git项目所处的默认公共分支、以及远端地址等。
- .repo/manifest.xml：
+ v, T" q2 x5 y, x9 w' s! f
repo工作目录中的内容同一时刻只能采用manifests中的一个xml文件做为其配置，该文件就是其软连接，通过init的-m选项指定采用哪个文件；另外，同一xml文件也可能处于manifests库的不同版本或者不同分支，通过init的-b选项指定使用manifests中的哪个分支，每次init命令都会从服务器更新最新的配置。这里通过-m指定的manifests中的xml文件中。
- .repo/repo：7 ?3 }5 E' i! z
此为repo脚本集的git库，用于repo管理所需的各种脚本，repo的所有子命令就是其中的对应脚本实现。这些脚本也通过git管理，.repo/repo/.git为对其应的git目录，用git进行版本管理。
' \4 r6 l. M% A$ `8 U- R7 o
3. 使用介绍
% A+ a1 [1 G& w" g" Trepo命令的使用格式如下所示：
- $ repo <COMMAND> <OPTIONS>
# ~6 `# v" g( R, A& |7 A4 Z可选的的有：help、init、sync、upload、diff、download、forall、prune、start、status，每一个命令都有实际的使用场景， 下面我们先对这些命令做一个简要的介绍：
; n5 P+ L) B! E. E/ ~
3.1 init. ]' ^4 S% }5 S% f& b' Z
- $ repo init -u <URL> [<OPTIONS>]
9 l: O. [! k5 w" W P3 ?1 H- -u：指定manifests这个远程git库的URL，manifests库是整个项目的清单。默认情况，这个git库只包含了default.xml一个文件，其内容可以参见Android的样本
- -m， –manifest-name：指定所需要的manifests库中的清单文件。默认情况下，会使用maniftests/default.xml
- -b， –manifest-branch：指定manifest.xml文件中的一个版本，，也就是俗称的“分支”运行该命令后，会在当前目录下新建一个.repo子目录：3 U- y5 F4 D$ w, Q7 y
% k! w# z( w+ L P$ _3 D; b.repo
├── manifests # 一个git库，包含default.xml文件，用于描述repo所管理的git库的信息
├── manifests.git # manifest这个git库的实体，manifest/.git目录下的所有文件都会链接到该目录
├── manifest.xml # manifests/default.xml的一个软链接
├── repo # 一个git库，包含repo运行的所有脚本
这些本地的目录是如何生成的呢？执行repo命令时，可以通过–trace参数，来看实际发生了什么。
- $ repo --trace init -u $URL -b $BRANCH -m $MANIFEST
" s: s" e3 v1 @ - --------------------
# Z T* g- M+ r5 N E+ E; w - mkdir .repo; cd .repo, Y! n. D) G' ?4 m' s3 |8 n
- git clone --bare $URL manifests.git& B! w3 Q" I* d9 A! h* i8 W2 c3 L
- git clone https://android.googlesource.com/tools/repo& U" c4 V3 _! Q7 b# O) M$ i% s" v7 S
- mkdir -p manifests/.git; cd manifests/.git
5 H9 `0 ~9 i& J/ n0 m - for i in ../../manifests.git/*; do ln -s $ı .; done" q5 c/ g$ e D4 S
- cd ..! F; b$ r0 ]1 }, B3 R& B! r5 E
- git checkout $BRANCH -- .- e6 J! i6 F1 ^9 t
- cd ..
' w, N2 M5 x) E* h( ?8 d - ln -s manifests/$MANIFEST manifest.xml
- V/ B# w. } h6 |) ]. t+ u8 i& B! A' F; C1 D) H
首先，在当前目录下创建.repo子目录，后续所有的操作都在.repo子目录下完成;
然后，clone了两个git库，其中一个是-u参数指定的manifests，本地git库的名称是manifest.git;另一个是默认的repo，后面我们会看到这个URL也可以通过参数来指定;
接着，创建了manifest/.git目录，里面的所有文件都是到manifests.git这个目录的链接，这个是为了方便对manifests目录执行git命令，紧接着，就会将manifest切换到-b参数指定的分支;
最后，在.repo目录下，创建了一个软链接，链接到-m参数制定的清单文件，默认情况是manifests/default.xml。
这样，就完成了一个多git库的初始化，之后，就可以执行其他的repo命令了。
, O5 s" H& B0 b* _, g- B我们还介绍几个不常用的参数，在国内下载Android源码时，会用到：
3 ^, y6 O+ h. t/ G d
- –repo-url：指定远程repo库的URL，默认情况是https: //android.googlesource.com/tools/repo，但国内访问Google受限，会导致这个库无法下载，从而导致repo init失败，所以可以通过该参数指定一个访问不受限的repo地址
- –repo-branch：同manifest这个git库一样，repo这个git库也是有版本差异的，可以通过该参数来指定下载repo这个远程git库的特定分支
- –no-repo-verify：在下载repo库时，会对repo的源码进行检查。通过–repo-url指定第三方repo库时，可能会导致检查不通过，所以可以配套使用该参数，强制不进行检查
3 H, B9 f( H' W) g) n% ~6 G# {$ `6 j
" W C2 h2 o1 Q$ ]# o3.2 sync6 |9 B2 i9 \# T8 ~8 b7 |
- $ repo sync [PROJECT_LIST]
- E |8 q. y1 t* E% b下载远程代码，并将本地代码更新到最新，这个过程称为“同步”。如果不使用任何参数，那么会对所有repo管理的进行同步操作;也可以PROJECT_LIST参数，指定若干要同步的PROJECT。 根据本地git库代码不同，同步操作会有不同的行为：
; d/ g2 k. h/ h/ z- Q# Q
- 当本地的git库是第一次触发同步操作时，那么，该命令等价于git clone，会将远程git库直接拷贝到本地
- 当本地已经触发过同步操作时，那么，该命令等价于git remote update && git rebase origin/，就是当前与本地分支所关联的远程分支 代码合并可能会产生冲突，当冲突出现时，只需要解决完冲突，然后执行git rebase --continue即可。
( y! I) W" `( R
当sync命令正确执行完毕后，本地代码就同远程代码保持一致了。在一些场景下，我们会用到sync命令的一些参数：
3 U0 k! {# k3 ]; ]9 O
- -j：开启多线程同步操作，这会加快sync命令的执行速度。默认情况下，使用4个线程并发进行sync
- -c, –current-branch：只同步指定的远程分支。默认情况下，sync会同步所有的远程分支，当远程分支比较多的时候，下载的代码量就大。使用该参数，可以缩减下载时间，节省本地磁盘空间
- -d, –detach：脱离当前的本地分支，切换到manifest.xml中设定的分支。在实际操作中，这个参数很有用，当我们第一次sync完代码后，往往会切换到dev分支进行开发。如果不带该参数使用sync， 则会触发本地的dev分支与manifest设定的远程分支进行合并，这会很可能会导致sync失败
- -f, –force-broken：当有git库sync失败了，不中断整个同步操作，继续同步其他的git库
- –no-clone-bundle：在向服务器发起请求时，为了做到尽快的响应速度，会用到内容分发网络(CDN, Content Delivery Network)。同步操作也会通过CDN与就近的服务器建立连接， 使用HTTP/HTTPS的U R L / c l o n e . b u n d l e 来初始化本地的 g i t 库， c l o n e . b u n d l e 实际上是远程 g i t 库的镜像，通过 H T T P 直接下载，这会更好的利用网络带宽，加快下载速度。当服务器不能正常响应下载 URL/clone.bundle来初始化本地的git库，clone.bundle实际上是远程git库的镜像，通过HTTP直接下载，这会更好的利用网络带宽，加快下载速度。 当服务器不能正常响应下载URL/clone.bundle来初始化本地的git库，clone.bundle实际上是远程git库的镜像，通过HTTP直接下载，这会更好的利用网络带宽，加快下载速度。当服务器不能正常响应下载URL/clone.bundle，但git又能正常工作时，可以通过该参数，配置不下载$URL/clone.bundle，而是直接通过git下载远程git库3 O2 z: k) M- j0 u0 _
1 Z& q# W* o+ k- k5 f# V. r
3.3 upload
$ i( n# e: h. l- $ repo upload [PROJECT_LIST]
) \0 B- l6 U# X7 [
. c5 H' @4 t3 H$ M2 e从字面意思理解，upload就是要上传，将本地的代码上传到远程服务器。upload命令首先会找出本地分支从上一次同步操作以来发生的改动，然后会将这些改动生成Patch文件，上传至Gerrit服务器。 如果没有指定PROJECT_LIST，那么upload会找出所有git库的改动;如果某个git库有多个分支，upload会提供一个交互界面，提示选择其中若干个分支进行上传操作。
0 _3 M3 t1 J* q, E
upload并不会直接将改动合并后远程的git库，而是需要先得到Reviewer批准。Reviewer查看改动内容、决定是否批准合入代码的操作，都是通过Gerrit完成。 Gerrit服务器的地址是在manifests中指定的：打开.repo/manifest.xml，这个XML TAG中的review属性值就是Review服务器的URL:
- <remote name="aosp"
8 `. O% n: E9 p% U - fetch=".."
0 x# c1 @: M' ?8 j1 M& C; h - review="https://android-review.googlesource.com/" />
Gerrit的实现机制不是本文讨论的内容，但有几个与Gerrit相关的概念，是需要代码提交人员了解的：
% N3 P+ n/ q7 K; d1 ~9 l- Reviewer：代码审阅人员可以是多个，是需要人为指定的。Gerrit提供网页的操作，可以填选Reviewer。当有多个git库的改动提交时，为了避免在网页上频繁的填选Reviewer这种重复劳动， upload提供了–re, –reviewer参数，在命令行一次性指定Reviewer
- Commit-ID：git为了标识每个提交，引入了Commit-ID，是一个SHA-1值，针对当次提交内容的一个Checksum，可以用于验证提交内容的完整性
- Change-ID：Gerrit针对每一个Review任务，引入了一个Change-ID，每一个提交上传到Gerrit，都会对应到一个Change-ID， 为了区分于Commit-ID，Gerrit设定Change-ID都是以大写字母 “I” 打头的。 Change-ID与Commit-ID并非一一对应的，每一个Commit-ID都会关联到一个Change-ID，但Change-ID可以关联到多个Commit-ID
- Patch-Set：当前需要Review的改动内容。一个Change-ID关联多个Commit-ID，就是通过Patch-Set来表现的，当通过git commit --amend命令修正上一次的提交并上传时， Commit-ID已经发生了变化，但仍可以保持Change-ID不变，这样,在Gerrit原来的Review任务下，就会出现新的Patch-Set。修正多少次，就会出现多少个Patch-Set， 可以理解，只有最后一次修正才是我们想要的结果，所以，在所有的Patch-Set中，只有最新的一个是真正有用的，能够合并的。
4 E' \# N0 z- P2 D! H
3 q- V; y2 y8 K a1 @0 L! i3.4 download5 l, h% X4 ^1 k- A4 @
- $ repo download <TARGET> <CHANGE>
8 h/ X; a! t }& G* h) [5 e* uupload是把改动内容提交到Gerrit，download是从Gerrit下载改动。与upload一样，download命令也是配合Gerrit使用的。
R( J" v- H( z8 ^ c+ f9 P$ z
- ：指定要下载的PROJECT，譬如platform/frameworks/base, platform/packages/apps/Mms
- ：指定要下载的改动内容。这个值不是Commit-ID，也不是Change-ID，而是一个Review任务URL的最后几位数字。 譬如，AOSP的一个Review任务https: //android-review.googlesource.com/#/c/23823/，其中23823就是。
8 _1 Z! U6 H9 Y
/ n( k# m8 ?% e8 R: m/ y7 K
3.5 forall+ B- i+ b1 T$ \% O& s3 ]
- $ repo forall [PROJECT_LIST] -c <COMMAND>
- P6 K, Z: F/ O: g S* g" C! i
; Z! {; [0 c( o q! w/ h7 T7 c对指定的git库执行-c参数制定的命令序列。在管理多个git库时，这是一条非常实用的命令。PROJECT_LIST是以空格区分的，譬如：
$ repo forall frameworks/base packages/apps/Mms -c "git status"" u$ v% M8 v7 G0 ~; z( o
表示对platform/frameworks/base和platform/packages/apps/Mms同时执行git status命令。 如果没有指定PROJECT_LIST，那么，会对repo管理的所有git库都同时执行命令。
1 {( y- A7 m+ m4 Y: h3 h
该命令的还有一些其他参数：
+ J) \- H. |! ~4 x- -r, –regex： 通过指定一个正则表达式，只有匹配的PROJECT，才会执行指定的命令
- -p：输出结果中，打印PROJECT的名称
8 b! l) K8 f( Y) Y8 Y; q' I, }" l
$ L2 [. y! Z* H$ J2 Y+ e3.6 prune# u j+ s! z+ {# |
- $ repo prune [<PROJECT_LIST>]
0 N" R+ |' _, L9 a7 K% i* o9 d6 [
# \( X6 T0 `4 e! J! }0 l7 E删除指定PROJECT中，已经合并的分支。当在开发分支上代码已经合并到主干分支后，使用该命令就可以删除这个开发分支。
随着时间的演进，开发分支会越来越多，在多人开发同一个git库，多开发分支的情况会愈发明显，假设当前git库有如下分支：
- * master: Z7 ]' h: I% e
- dev_feature1_201501 # 已经合并到master6 g3 [% B0 a0 b" y$ y3 l! o
- dev_feature2_201502 # 已经合并到master5 G7 Q" ?: U* c+ X& }9 U9 a6 m
- dev_feature3_201503 # 正在开发中，还有改动记录没有合并到master
8 x6 D7 G& Q4 `4 K' n2 \$ m# z那么，针对该git库使用prune命令，会删除dev_feature1_201501和dev_feature2_201502。
定义删除无用的分支，能够提交团队的开发和管理效率。prune就是删除无用分支的”杀手锏“。
2 A& g4 W6 F s/ Y3 Z+ _
3.7start
. ?1 ^, G: L+ s- $ repo start <BRANCH_NAME> [<PROJECT_LIST>]
, a" r" u3 U/ c在指定的PROJECT的上，切换到<BRANCH_NAME>指定的分支。可以使用–all参数对所有的PROJECT都执行分支切换操作。 该命令实际上是对git checkout命令的封装，<BRANCH_NAME>是自定义的，它将追踪manifest中指定的分支名。
% P2 S/ t6 t6 ]& `5 `% c- |
当第一次sync完代码后，可以通过start命令将git库切换到开发分支，避免在匿名分支上工作导致丢失改动内容的情况。
* Z9 @- e' ~/ |: z3.8 status; c7 v% P! j& x6 Z+ E) O5 t. _$ o0 ?
- $ repo status [<PROJECT_LIST>]
3 Q' r3 r0 W. Z5 h) J& a V5 L
# L! i: R3 M4 `2 fstatus用于查看多个git库的状态。实际上，是对git status命令的封装。
4. 使用实践
9 z/ k/ s7 h9 z1 a A% w* MAndroid推荐的开发流程是：
- repo init初始化工程，指定待下载的分支
- repo sync下载代码
- repo start将本地git库切换到开发分支(TOPIC BRANCH)
- 在本地进行修改，验证后，提交到本地
- repo upload上传到服务器，等待review! u% P7 x, @0 u0 G( W
5 X9 M( |7 T) H o0 n! ]
在实际使用过程中，我们会用到repo的一些什么子命令和参数呢？哪些参数有助于提高开发效率呢？下面我们以一些实际场景为例展开说明。
, g b. [& l0 T1 O) F: d4.1 对项目清单文件进行定制通过local_manifest机制，能够避免了直接修改default.xml，不会造成下次同步远程清单文件的冲突。
+ ^0 j% P+ W1 s% N( X1 Y" E
CyanogenMod(CM)适配了上百款机型，不同机型所涉及到的git库很可能是有差异的。以CM对清单文件的定制为例，通过新增local_manifest.xml，内容如下：
- <manifest>
( [% V& ~, C: d - <!-- add github as a remote source -->
0 i; |9 ]8 A+ E! I - <remote name="github" fetch="git://github.com" />5 d1 t% E3 @% E- O9 _" u. o5 Y& C D: ]
- 1 D" g) _! s8 E! r; J
- ) q+ v. [* u2 J3 L1 R, X
- <!-- remove aosp standard projects and replace with cyanogenmod versions -->3 r0 |6 M2 W& x
- <remove-project name="platform/bootable/recovery" />
# G! H' p' ]/ V" u - <remove-project name="platform/external/yaffs2" />/ L: @) G1 K% T% s% P- d/ w
- <remove-project name="platform/external/zlib" /># n$ p( R% g& r2 @; d- R2 W
- <project path="bootable/recovery" name="CyanogenMod/android_bootable_recovery" remote="github" revision="cm-10.1" />
: P( r$ _7 M) D - - w) X+ R4 M) F8 \% Z
- <project path="external/yaffs2" name="CyanogenMod/android_external_yaffs2" remote="github" revision="cm-10.1" />
6 `7 y4 ?7 s3 R- a4 P - <project path="external/zlib" name="CyanogenMod/android_external_zlib" remote="github" revision="cm-10.1" />9 W6 \0 V7 P: p
- # I+ x" U. n& z d+ `
- <!-- add busybox from the cyanogenmod repository -->' e+ ~9 r" W# H; m) f
- <project path="external/busybox" name="CyanogenMod/android_external_busybox" remote="github" revision="cm-10.1" />
S! l- }9 r [6 w
6 g/ {& Q* q2 P/ s- T3 ^& ^) P; @9 n# s-
( O- Y' c* q9 o; z. a - </manifest>
local_manifest.xml会与已有的default.xml融合成一个项目清单文件manifest.xml，实现了对一些git库的替换和新增。 可以通过以下命令导出当前的清单文件，最终snapshot.xml就是融合后的版本：
- $ repo manifest -o snapshot.xml -r
( L1 C* B* q4 j在编译之前，保存整个项目的清单，有助于问题的回溯。当项目的git库发生变更，需要回退到上一个版本进行验证的时候，只需要重新基于snapshot.xml初始化上一个版本即可：
- $ cp snapshot.xml .repo/manifests/, V+ }/ A) k& Y3 t g7 x
- $ repo init -m snapshot.xml # -m 参数表示自定义manifest7 B* R8 k- h5 P `( W2 a; F2 Q
- $ repo sync -d # -d 参数表示从当前分支脱离，切换到manifest中定义的分支
6 ^- q4 E+ b+ U8 y9 m/ a4.2 解决无法下载Android源码9 l' s1 d) M; f. ~
在repo init的时候，会从远程下载manifests和repo这两个git库，默认情况下，这两个git库的地址都是写死在repo这个python脚本里面的。对于AOSP而言，这两个git库的地址显然是google提供的。但由于google访问受限的缘故，会导致init时，无法下载manifests和repo。这时候，可以使用init的-u和–repo-url参数，自定义这两个库的地址，辅以–no-repo-verify来绕过代码检查。
- $ repo init --repo-url [PATH/TO/REPO] -u [PATH/TO/MANIFEST] -b
& M* U" e' H- {- I5 u4 e0 ~( l3 C - [BRANCH] --no-repo-verify* z9 I" N5 e7 x8 Z- B
- $ repo sync
$ |# l% |$ t, k/ ?
; ?* Z$ p1 S5 q1 B& V6 v& b4.3 更快更省的下载远程代码repo默认会同步git库的所有远程分支的代码，但实际开发过程中，用到的分支是有限的。使用sync的-c参数，可以只下载manifest中设定的分支，这会节省代码下载时间以及本地的磁盘空间：
) z, X7 E2 H: ^6 c% F5 t
如果实际开发过程中，需要用到另外一个分支，而又不想被其他分支干扰，可以在已有的工程根目录下，使用如下命令：
- $ repo manifest -o snapshot.xml -r4 K% {) Y1 c4 F6 r$ i
- $ repo init -u [PATH/TO/MANIFEST] -b [ANOTHER_BRANCH]% m2 z0 ?0 T: S: j
- $ repo sync -c -d
5 `6 C( O9 d# Z% d1 L# c! b4 h+ e; y1 U, W; I
以上命令序列，相当更新了manifest，而且仅仅只下载ANOTHER_BRANCH的代码，这样本地只保存了两个分支的代码。利用保存的snapshot.xml，还能将所有git库方便的切换回原来的分支。
2 b Q; \( T. [: S3 K
如果本地已经有一份Android源码，假设路径为~/android-exsit，想要下载另一份新的Android源码，通过–reference参数，在数分钟以内，就能将代码下载完毕：
- $ mkdir ~/android-new && cd ~/android-new! W7 l/ p$ C3 E; I: S9 }% W
- $ repo init --reference=~/android-exsit -u [PATH/TO/MANIFEST] -b [BRANCH]; }2 R6 E: a. u4 m) X: F
- $ repo sync -c
; j: E6 I, f; l( k* C* O+ l, ~ 4.4 避免在匿名分支上工作在sync完代码后，所有git库默认都是在一个匿名分支上(no branch)，很容易会由于误操作导致丢失代码修改。可以使用如下命令将所有的git库切换到开发分支：
- $ repo start BRANCH --all
( [2 Z! }5 X$ X8 B0 g" P& s+ ?2 b$ _. [8 ?5 F' w
4.5 使用upload提交代码开发人员可能同时在多个git库，甚至多个分支上，同时进行修改，针对每个git库单独提交代码是繁琐的。可以使用如下命令，一并提交所有的修改：
5 B6 z3 A, C) g& z0 l) h2 H
不用担心会漏提交或者误提交，upload会提供一个交互界面，开发人员选择需要提交的git库和分支即可。
如果需要省去Gerrit上填写reviewer的操作，可以使用–reviewer参数指定Reviewer的邮箱地址：
- $ repo upload --reviewer="R.E.viewer@google.com"
) U/ J: A" {' R4 J/ C) N3 ]* {8 e4.6 定期删除已经合并的开发分支Git鼓励在修复Bug或者开发新的Feature时，都创建一个新的分支。创建Git分支的代价是很小的，而且速度很快，因此，不用担心创建Git分支的成本，而是尽可能多地使用分支。
* T3 n+ P! p4 n7 H
随着时间的演进，开发分支会越来越多，而一些已经合并到主干的开发分支是没有存在价值的，可以通过prune命令定期删除无用的开发分支：
- $ repo prune [PROJECT_LIST]
, g y6 {0 O6 R# G9 H5 v
0 t( W# O9 ~0 B# _% T4.7 同时操作多个git库对于部分开发人员而言，同时操作多个git库是常态，如果针对每个git库的操作命令都是相同的，那么可以使用如下命令一次性完成所有操作:
- $ repo forall -c "git branch | grep tmp | xargs git branch -D; git branch"
- G+ b& {9 h4 |( ^+ q参数-c指定的命令序列可以很复杂，多条命令只需要用“;”间隔。
, I" m1 l0 K. S! j
! O$ W5 x$ V) j% W: s+ `, N/ D. B
作者: Sleep_xz 时间: 2024-10-28 16:26
作者: 武汉万象奥科 时间: 2024-10-29 09:23
) b4 ]6 @- r; h& ]6 L7 x
目前还没有哈
! w3 F K2 D5 v' u
| 欢迎光临 EDA365电子论坛网 (https://bbs.eda365.com/) |
Powered by Discuz! X3.2 |