gitaiとは？
gitaiは、AIコーディングエージェント向けに設計されたオープンソースのバージョン管理システムです。クライアントをオンラインに保ち、必要なオブジェクトとパスだけを取得し、ソース管理操作をサーバーに送信する、サーバー中心のアプローチを実装しています。
このプロジェクトは、Anthropicが公開しているScionの設計説明に着想を得ていますが、gitaiは独立した実装です。MITライセンスで提供され、ベンダーに依存せず、サーバーが言語モデルを呼び出す必要もありません。AIを利用する操作では、任意のプロバイダー、決定論的なツール、またはAIプロバイダーなしを選択できます。
内部では、gitaiは通常のGitリポジトリを使用しながら、履歴クエリ、ランディング、チェンジセット追跡、リポジトリの調整をサーバーに移します。このモデルは、共有ブランチへ変更を迅速に反映する必要がある、多数の短命タスクを伴うワークロードを想定しています。
主な機能
- 選択的なデータアクセス：オブジェクトサービスは個々のオブジェクトとスパースツリーを提供します。
graft cloneとgraft sparseコマンドは、要求されたパスだけを具体化します。 - サーバー側の履歴：blame、パス履歴、祖先関係、コード検索はサーバー上で実行され、派生データとしてメモ化されます。
- 並行ランディング：
UserLandは変更を現在のブランチ先端へリベースし、従来のマージキューの代わりにcompare-and-swap更新を使用します。並行するランディングは、1回の参照更新にまとめることができます。 - コンフリクト解決：競合するランディングでは、バージョン管理されたベンダー中立プロトコルを介して、選択したリゾルバーを使用できます。
- チェンジセットログ：受け入れられた参照更新では、その操作と実行者が順序付きログに記録され、クライアントから一覧表示または監視できます。
- スケーラブルなストレージ：SQLiteまたはPostgreSQLは、チェンジセット、参照、レビュー、先行書き込みログを格納し、コンテンツアドレス付きパックはファイルストレージ、S3、GCS、またはAzureに配置できます。
- エージェント制御：エージェントごとのトークン、RPC許可リスト、ブランチポリシーによって、エージェントが実行できる操作を決定します。
- 検証と監視：
graft-verifyは先端のテスト、失敗箇所の二分探索、原因となった変更のリバートを実行できます。スーパーファンと呼ばれる監視エージェントはチェンジセットストリームを追跡し、Slack経由で報告できます。 - 厳密なキャッシュ：
graft-cacheはデーモン層およびリージョン層で不変オブジェクトをキャッシュし、各オブジェクトを検証できます。
アーキテクチャの仕組み
エージェント、CIジョブ、スパースワークスペースは、Graft CLIまたはGo SDKを介してgRPCでgitaiサーバーと通信します。オプションのgraft-cacheデーモンをサーバーの前段に配置し、追加のキャッシュ層を提供することもできます。
サーバーは、ランディング、オブジェクトアクセス、チェンジセット、派生データ、検索、レビューを処理します。その書き込みパスでは、チェンジセットと各参照に対するcompare-and-swap操作を組み合わせます。データベースストレージには、チェンジセットの先行書き込みログ、参照、変更履歴、レビューを格納します。オブジェクトストレージには、コンテンツアドレス付きパックを格納します。
サーバーノードは、再構築可能なステートレスキャッシュとして設計されています。これにより、デプロイメントの拡大に応じてノードを追加できます。ローカルGitリポジトリは、どのノードでも再構築できるキャッシュとして引き続き利用できます。
詳しくは、プロジェクトのアーキテクチャドキュメントとストレージドキュメントを参照してください。
gitaiのインストールとビルド
1. 前提条件をインストールする
現在、gitaiにはLinuxまたはmacOS、Go 1.26、Cツールチェーン、Meson、Ninjaが必要です。ビルドでは同梱されたGitをコンパイルするため、開始前に必要なネイティブビルドツールが利用できることを確認してください。
2. リポジトリをクローンする
git clone https://github.com/feder-cr/git-ai.git
cd git-ai3. バイナリをビルドする
Makeターゲットを実行して、サーバー、CLI、補助ツールをビルドします：
make build生成されたバイナリは_build/binに配置されます。CLIと利用可能なコマンドを確認するには、次を実行します：
./_build/bin/graftクイックスタートを実行する
リポジトリには、サーバー、キャッシュデーモン、2つのエージェント、ランディング操作を含む一時的なgitai環境を起動する例が用意されています：
examples/graft/quickstart.shこれは、永続的なデータベース、オブジェクトストア、デプロイメントを準備せずに、主要なワークフローを確認する最も簡単な方法です。この例では一時ディレクトリを使用するため、学習や実験に適しています。
独自のサーバーを実行する
1. サンプル設定から始める
カスタムサーバー設定の出発点としてexamples/graft/config.tomlを使用します。ビルドしたバイナリでサーバーを起動できます：
_build/bin/gitaly serve config.tomlソースツリー内では、サーバー側の拡張機能をGraftと呼びます。この名前は、[graft]設定セクション、graft CLI、internal/graftパッケージ、Graftドキュメントで確認できます。
2. データベースとオブジェクトストレージを追加する
リポジトリの状態をデータベースとオブジェクトストレージに保存するデプロイメントでは、設定に[graft.storage]セクションを追加します。文書化された移行手順では、まずshadowモードで開始し、リポジトリをインポートしてからauthoritativeモードに切り替えます。
正確な設定方法と移行の詳細については、ストレージガイドを参照してください。対応するストレージモデルでは、調整データにSQLiteまたはPostgreSQLを使用し、コンテンツアドレス付きパックにはファイル、S3、GCS、またはAzureストレージを使用します。
エージェントの変更を扱う
従来のGitワークフローでは、各作業者がリポジトリをクローンし、ローカルで開発して、共有ブランチにプッシュできます。gitaiでは、エージェントはサーバーへの接続を維持し、必要なデータだけを要求できます。
エージェントはスパースワークスペースを使用して、実体化するパスを制限できます。関連するコマンドは次のとおりです。
graft cloneは、リポジトリの選択したビューを実体化します。graft sparseは、タスクに必要なパスだけを要求または調整します。
エージェントが変更を提供できる状態になると、UserLandはその変更を現在の先端にリベースし、比較交換方式による更新を試みます。複数のエージェントが1つのブランチに同時に変更を反映する場合、gitaiはそれらの操作を1回の参照更新にまとめることができるため、すべてのエージェントを個別のマージキューに通す必要がありません。
反映時に競合が発生した場合は、競合解決ドキュメントに従ってリゾルバーを設定してください。リゾルバーには、LLMプロバイダー、決定論的ツール、または外部AIプロバイダーなしの方式を使用できます。
チェンジセット、レビュー、検証を確認する
チェンジセット履歴
受け入れられたすべての参照更新は、チェンジセットログのエントリになります。エントリには操作と実行者が含まれるため、クライアントは順序付けられた記録を一覧表示したり、ライブで監視したりできます。このストリームは、特定のコンポーネントに関係する変更を追跡する監視エージェントの動作にも利用できます。
レビューとポリシー
gitaiには、意味に基づく承認ルールに対応したエージェント向けレビュー機能があります。たとえば、コメントのみの変更には、ロジックの変更より少ない承認数を要求できます。エージェントのセキュリティ制御には、エージェントごとのトークン、RPC許可リスト、ブランチポリシーも含まれます。
サーバーを自動化されたユーザーに公開する前に、レビュードキュメントとエージェントセキュリティドキュメントを読んでください。
反映後の検証
graft-verifyワークフローは、変更が反映された後にブランチの先端をテストします。テストが失敗した場合は、変更を二分探索し、失敗の原因となった変更を元に戻せます。これにより、統合を継続的に行い、壊れた先端の原因となった変更をシステムが特定するワークフローを実現できます。
対応するワークフローと設定については、検証ガイドを参照してください。
高度なデプロイのヒント
- キャッシュを意図的に使用する: エージェントやCIジョブがデーモンまたはリージョン別のキャッシュ層をまたいで不変オブジェクトに高速アクセスする必要がある場合は、
graft-cacheを追加します。 - 調整とオブジェクトストレージを分離する: チェンジセットと参照にはSQLiteまたはPostgreSQLを使用し、リポジトリパックにはオブジェクトストレージバックエンドを設定します。
- ノードを追加して拡張する: サーバーノードは再構築可能なキャッシュとして設計されているため、ノードを追加しても、各ノードが独立した信頼できる状態を保持する必要はありません。
- 反映に関するドキュメントを読む: 反映とバッチ処理のガイドでは、比較交換方式のワークフローと同時更新について説明しています。
- 現在の制限事項を確認する: これはバージョン0.1.0であり、1.0より前にインターフェースが変更される可能性があります。また、パックのガベージコレクションなどの既知の不足事項はLIMITATIONS.mdに記載されています。
- 設計ドキュメントを活用する: PLAN.mdからPLAN6.mdまでのドキュメントで、実装の rationale と進化の過程を説明しています。
まとめ
gitaiは、多数のコーディングエージェントが同時に作業するリポジトリ向けに、サーバー中心のソース管理モデルを適応させます。Graft CLIとサーバーは、スパースなデータアクセス、サーバー側の履歴管理、比較交換方式による反映、競合解決、チェンジセットログ、レビュー、検証、拡張可能なストレージを提供します。
まずmake buildとexamples/graft/quickstart.shを実行し、ワークフローを理解したら、設定済みのサーバーと永続ストレージに移行してください。実装や運用について詳しく知りたい場合は、プロジェクトのQuickstart、設定リファレンス、およびアーキテクチャドキュメントを利用してください。