Bazel は、リポジトリと呼ばれるディレクトリ ツリーに整理されたソースコードからソフトウェアをビルドします。ワークスペースは定義済みのリポジトリのセットで構成されます。リポジトリ内のソースファイルは、ネストされたパッケージ階層に編成されています。各パッケージは、関連するソースファイルのセットと 1 つの BUILD ファイルを含むディレクトリです。BUILD ファイルは、ソースからビルドできるソフトウェア出力を指定します。
リポジトリ
Bazel ビルドで使用されるソースファイルは、リポジトリ（多くの場合、repos と短縮されます）にまとめられています。リポジトリは、ルートに境界マーカー ファイルがあるディレクトリ ツリーです。このような境界マーカー ファイルは、MODULE.bazel、REPO.bazel、以前のコンテキストでは WORKSPACE、WORKSPACE.bazel などにできます。
現在の Bazel コマンドが実行されているリポジトリをメイン リポジトリといいます。その他の（外部）リポジトリは、リポジトリ ルールによって定義されます。詳細については、外部依存関係の概要をご覧ください。
ワークスペース
ワークスペースは、同じメイン リポジトリから実行されるすべての Bazel コマンドで共有される環境です。メイン リポジトリと、定義済みのすべての外部リポジトリのセットが含まれます。
これまで、「リポジトリ」と「ワークスペース」のコンセプトは混同されてきました。「ワークスペース」という用語はメイン リポジトリを指すために使用され、場合によっては「リポジトリ」の同義語として使用されることさえあります。
パッケージ
リポジトリ内のコード編成の基本単位はパッケージです。パッケージは、関連ファイルのコレクションと、それらを使用して出力アーティファクトを生成する方法の仕様です。
パッケージは、BUILD または BUILD.bazel という名前の BUILD ファイルを含むディレクトリとして定義されます。パッケージには、そのディレクトリ内のすべてのファイルと、その下のすべてのサブディレクトリが含まれます（ただし、それ自体に BUILD ファイルが含まれるファイルは除きます）。この定義から、ファイルやディレクトリが 2 つの異なるパッケージの一部になることはできません。
たとえば、次のディレクトリ ツリーには、my/app とサブパッケージ my/app/tests の 2 つのパッケージがあります。my/app/data はパッケージではなく、my/app パッケージに属するディレクトリです。
src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc
ターゲット
パッケージはターゲットのコンテナで、パッケージの BUILD ファイルで定義されています。ほとんどのターゲットは、ファイルとルールの 2 つのプリンシパルの種類のいずれかです。
ファイルはさらに 2 種類に分類されます。ソースファイルは通常、ユーザーの作業によって記述され、リポジトリにチェックインされます。生成ファイル（派生ファイルや出力ファイルとも呼ばれます）はチェックインされず、ソースファイルから生成されます。
2 つ目の種類のターゲットは、ルールで宣言されます。各ルール インスタンスは、一連の入力ファイルと一連の出力ファイルの関係を指定します。ルールへの入力をソースファイルにすることもできますが、他のルールの出力にすることもできます。
ルールへの入力がソースファイルであっても生成されたファイルであっても、ほとんどの場合重要ではありません。重要なのは、そのファイルの内容のみです。これにより、複雑なソースファイルを、ルールによって生成されたファイルに置き換えることが簡単になります。たとえば、高度に構造化されたファイルを手動で管理する負担が煩雑になり、そのファイルを導出するためのプログラムを作成する場合などです。このファイルの使用者を変更する必要はありません。逆に、生成されたファイルは、ローカルの変更のみを含むソースファイルで簡単に置き換えることができます。
ルールへの入力には、他のルールも含めることができます。このような関係の正確な意味は、多くの場合、非常に複雑で言語やルールに依存しますが、C++ ライブラリ ルール A が入力に別の C++ ライブラリ ルール B を持つ場合もあります。この依存関係の効果により、A はコンパイル時に B のヘッダー ファイルを使用でき、リンク時に A は B のシンボルを使用でき、実行中には B のランタイム データを A で使用できます。
ルールによって生成されるファイルは常にルール自体と同じパッケージに属します。別のパッケージにファイルを生成することはできません。ただし、ルールの入力が別のパッケージから行われることは珍しくありません。
パッケージ グループは、特定のルールへのアクセスを制限することを目的としたパッケージのセットです。パッケージ グループは、package_group 関数で定義されます。プロパティには、パッケージに含まれるパッケージのリスト、名前、パッケージに含まれる他のパッケージ グループの 3 つのプロパティがあります。これを参照する方法は、ルールの visibility 属性または package 関数の default_visibility 属性からのみです。ファイルの生成や使用は行いません。詳細については、package_group のドキュメントをご覧ください。