第3章 · レッスン 09 / 17

読む現場の言葉を身につける

リポジトリ:プロジェクトの入れ物

サイトやアプリの実体が、どこにあるかをやさしく知る

  • 目安 10 分
  • 進捗 9/17
第3章のレッスン一覧9 / 17
  1. 09リポジトリ:プロジェクトの入れ物10分
  2. 10ブランチとコミット:安全に試す技術12分
  3. 11Pull Request を読み解く14分
  4. 12品質の見分け方12分

このレッスンのゴール

  • リポジトリを日常語と開発者語の両方で説明できる
  • 『ファイルの集まり+履歴』だと理解する
  • どのリポジトリを触るべきか判断する視点を持つ

日常語で言うと

リポジトリは、プロダクトを構成するファイル一式の保管庫です。文章、画像、設定、プログラムが入り、誰がいつ何を変えたかの記録も一緒に持ちます。

Cloud Agent に『このリポジトリで作業して』と指定するのは、『この保管庫を開いて仕事して』と渡すのと同じです。

開発者語への接続

開発者はリポジトリを repo と呼び、Git で履歴管理されたディレクトリとして扱います。GitHub 上の1プロジェクトが、だいたい1つ(または関連する複数)のリポジトリです。

複数リポジトリがある世界

会社によっては、見た目のサイト、予約システム、社内ツールで保管庫が分かれます。Agent にも multi-repo(複数リポジトリ)環境があります。環境に複数リポジトリを入れておくと、Agent は必要な保管庫をまとめて開き、直したリポジトリごとに PR を出せます。

最初は『今回の変更はどの保管庫か』を必ず確認する習慣だけで十分です。別プロダクトを触らせないことが、安全の基本です。フロントと API を同時に直す仕事が出てきたら、詳しい人に multi-repo 環境の有無を聞いてみましょう。

multi-repo で長時間かかる仕事を任せたいときは注意です。公式では multi-repo 環境では長期実行(Long running agents)がまだ使えません。日をまたぐ大きな変更は、単一リポジトリにまとめるか、保管庫ごとに Agent を分けると安心です。

依存する別の保管庫(サブモジュール)

1つのプロジェクトが、別の保管庫を部品として取り込んでいることがあります(Git のサブモジュールなど)。公式では、Cloud Agent は作業対象の保管庫に加え、こうした依存先にも読み書きできる権限が必要です。

権限が足りないと clone や push の段階で止まり、『コードが書けない』のではなく『接続が足りない』ように見えます。Integrations で Selected repositories(選んだ保管庫だけ)を使っているチームは、依存先の保管庫も選び忘れていないか、管理者に確認しましょう。

置き場は GitHub だけではない(Origin)

保管庫の置き場は GitHub が最多ですが、Cursor の Origin(早期ベータ)にも置けます。cursor.com/codebase が入口です。Find repo... で探し、保管庫を開けば git なしでコードと PR を見られます。緑の Code から clone URL をコピーできます。Cloud Agent は Origin の保管庫でも clone・ブランチ・commit・push ができます。手元で git を打たなくても、Agent に『Origin に置いて』と頼むと、保管庫の作成まで任せられます(公式 Origin create-repository)。

Origin 上で作った保管庫の PR は Origin 側に出ます。GitHub から同期(ミラー)した保管庫では GitHub が正本で、PR も GitHub 側です。同期した保管庫の clone URL(https://origin.cursor.com/{owner}/{repo}.git)へ git push すると GitHub へ届き、Origin は写しとして追従します(公式 Origin git / integrations)。『GitHub に PR が無い』と感じたら、まず保管庫が Origin ホストか GitHub 同期かをアイコンで確認してください。

GitHub から同期した保管庫で、名前が origin/ で始まる枝は Origin 側だけの作業場です。GitHub が一時的に使えないとき向けで、GitHub の PR の先頭にはなりません。詳しい人が origin push local すると origin-local という送り先(...git/local)ができます。普段の Cloud Agent の PR は普通の枝名です(公式 Origin git / pull requests / CLI)。

公開や CI も置き場で分かれます。Origin 上で作った保管庫は Settings の Apps から Vercel(公開とプレビュー)、Depot / Buildkite(CI)をつけられます。Apps のインストールはコードベース設定の Manage Apps です。GitHub 同期の保管庫では、CI は GitHub 側のままです(公式 Origin settings / codebase-settings)。同期をやめて Origin を正本にしたいときは Settings → General の Detach from GitHub。GitHub 側の保管庫は消えません。Origin 上の PR がマージできないときは、同じ Settings の Rules and Protections(GitHub のブランチ保護の対応)を見ます。

理解チェック

  • リポジトリを『ファイル一式+履歴の保管庫』と言い換えられる
  • 依頼前に『対象リポジトリはどれか』を確認する理由を言える
  • 複数保管庫にまたがる仕事では multi-repo 環境があると言える
  • multi-repo では長期実行がまだ使えない公式制限を知っている
  • 依存リポジトリやサブモジュールにも読み書き権限が要る場合があると説明できる
  • Selected repositories では Manage Connections で依存保管庫も追加依頼できる
  • Origin 上の保管庫と GitHub 同期の保管庫で、PR の出る場所が違うと知っている
  • Depot / Buildkite は Origin 上で作った保管庫の CI で、GitHub 同期では GitHub 側だと知っている
  • cursor.com/codebase で git なしに保管庫とコードを開けると知っている
  • Origin 上の PR がマージできないときは Rules and Protections を疑える
  • Agent に『Origin に置いて』と頼むと保管庫作成まで任せられると知っている
  • GitHub 同期の origin/ で始まる枝は Origin 側だけで、GitHub の PR にならないと知っている

開いただけでは「済」になりません。チェックできたら押してください。

実践

自分が触るリポジトリを1つ開き、トップレベルのフォルダ名を書き出してみましょう。Agent に『各フォルダの役割を初心者向けに説明して』と依頼してみてください。別の保管庫を部品として取り込んでいる(サブモジュール)なら、Integrations の Selected repositories に依存先も含まれているか、GitLab なら Manage → Sync Repos も、管理者に一言確認してみましょう。

このレッスンで出てくる用語

全部覚える必要はありません。気になる言葉だけ開いてみてください。

用語集を全部見る →

いま身についている開発者スキル

リポジトリ構成 / モノレポとマルチレポの感覚