| ア | イ | ウ | エ | オ |
| カ | キ | ク | ケ | コ |
| サ | シ | ス | セ | ソ |
| タ | チ | ツ | テ | ト |
| ナ | ニ | ヌ | ネ | ノ |
| ハ | ヒ | フ | ヘ | ホ |
| マ | ミ | ム | メ | モ |
| ヤ | ユ | ヨ | ||
| ラ | リ | ル | レ | ロ |
| ワ | ヰ | ヴ | ヱ | ヲ |
| ン |
| A | B | C | D | E |
| F | G | H | I | J |
| K | L | M | N | O |
| P | Q | R | S | T |
| U | V | W | X | Y |
| Z | 数字 | 記号 | ||
複数のGitプロジェクトをまとめて管理するためのツール。
一般的に、バージョン管理システムは一つのリポジトリで一つのプロジェクトを管理する前提である。Gitも例外ではない。
開発規模が小さいうちはこれでも良いのだが、開発規模が大きい場合、全体をひとつのリポジトリとすることは困難となる。
そこで全体を幾つかに分割する。具体的には、ディレクトリで大まかに分割し、それぞれを小さなGitリポジトリとする。その複数の小さなGitリポジトリをrepoで統合管理することになる。
repoでは、この各々の小さなGitリポジトリ(ディレクトリ)をプロジェクトと呼び、プロジェクトの一覧をマニフェストファイルmanifest.xmlに記載することで全体を管理する仕組みとなっている。
例えばOSの開発などのように、様々な機能が同時並行的に開発される場合、全く無関係のものを同じリポジトリで管理する必要性も必然性もない。
更新が激しくなり、履歴も分かりにくくなり、さらに、コンフリクトが発生しやすくpushも困難になる。そこで、機能ごとに分割することになる。
Androidの場合、使用するプロセッサー環境などにもよるが、一般的なQUALCOMM(クアルコム)チップセットを使ったシステムであれば、大きくAMSSとLinuxに分けられ、さらにLinux側(Android側)は、無数のディレクトリがあり、Linux側は大小さまざま約300個ものリポジトリで管理されている。
そこで使われるのがrepoであり、複数のGitリポジトリを管理することでGitを補完する。
より具体的には、AMSSとandroid/kernelはおのおの単独のリポジトリで、kernel以外のandroid以下の他のディレクトリについては、無数のリポジトリが存在することになる。android/hardwareディレクトリを例とすると、この中にある各サブディレクトリごとにリポジトリがあるが、メーカー独自の機能などを実装するディレクトリについては、この中のさらに子ディレクトリごとに細かくリポジトリが分けられている。
repoは多機能で様々な機能があるが、例えば、repo forallを使うと(遅いが)全てのディレクトリにあるリポジトリに対する操作ができる。
repo forall -c 'git pull hogehoge'
全てのディレクトリを列挙する機能を用いると、全てのディレクトリに対してgit pullする(この例ではhogehogeリポジトリからpullする)ことができる。
コメントなどを投稿するフォームは、日本語対応時のみ表示されます