Git sparse-checkoutとpartial clone：減らす対象の違い
作業ツリー、取得するオブジェクト、コミット履歴を区別して、sparse-checkoutとpartial・shallow cloneの選択を考える。
発行・訂正窓口：infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
Gitのsparse-checkoutは作業ツリーに現れるパスを減らし、partial cloneは最初に取得するオブジェクトを減らす。shallow cloneはコミット履歴の範囲を狭める別の選択だ。同じ機能として扱うと、ディスク利用やオフライン作業への期待がずれる。まず何を減らす必要があるかを区別したい。
実際のリポジトリーや性能測定ではなく概念図だ。
作業ファイルとオブジェクト保存は別の層
公式マニュアルは、選んだディレクトリーやパターンに一致するファイルを作業ツリーに置く仕組みを説明する。エディターで一部のフォルダーしか見えなくても、保存済みオブジェクトが消えたとは限らない。作業ツリーは編集するファイルの姿であり、オブジェクトは内容と履歴の基盤になる。
大きなモノレポで一つのサービスを編集するなら、作業範囲を絞ることが目的に合う。ただし全体を取得済みなら、フォルダーを表示しなくても最初の転送は取り消されない。取得データと見えるファイルを別々に測ることで、選んだ機能が問題を解決するか判断できる。 作業ツリーの説明
cone modeはディレクトリー選択が中心
公式文書のcone modeはディレクトリー一覧で範囲を指定し、任意パターンを使う方式とは異なる。non-coneの欠点も記載されている。サービスのフォルダーを選ぶ用途では、まずディレクトリーのモデルを理解すると管理しやすい。二つの方式の費用を同じと考えるべきではない。
選択外のファイルが見えなくても、ファイル削除と混同しないことが大切だ。他のGit操作も選択範囲を考慮する。マージや競合処理で必要なパスが実体化する場合もある。文書のreapplyは、競合を解決して影響する変更を整理した後に作業ツリーを目的の範囲へ戻す場面を扱っている。
coneの選択は指定ディレクトリー以下を再帰的に含み、ルートと祖先の位置にあるファイルも含む。仮に services/api を選ぶと、ルートのファイルや services 直下のファイルも現れ得る。ただし services/web のような兄弟ディレクトリー全体を再帰的に選ぶわけではない。フォルダー一覧だけでなくファイルの位置も区別したい。 coneの包含規則
専門的視点：後から取得する費用
Git開発者Derrick StoleeのGitHub分析では、blobless partial cloneは到達可能なコミットとtreeを取得し、ファイル内容のblobは必要時に取得すると説明する。全履歴のファイル内容を最初から受け取らず、履歴構造を先に持つ方式だ。2020年の分析なので、実際のサーバーとクライアントの対応は別途確認する。
不足する内容を後から受け取るため、後続操作でネットワークが必要になる可能性がある。最初の転送が小さくても、すべての操作が高速化したり完全なオフライン作業ができたりするとは限らない。普段使う差分表示や過去内容の調査で、どのデータが必要になるかを見るのが実務的な確認方法だ。
git clone --sparse は最初に最上位のファイルだけを置く。--filter=blob:none だけでは最初のチェックアウトに必要なblobの取得までなくならない。--no-checkout による省略は別の選択だ。フィルターはサーバーの対応次第で拒否もあり得る。取得済みのオブジェクトはローカルで使え、全操作が毎回リモートへ接続するわけではない。 cloneオプションの範囲 不足オブジェクトの依存 過去の著者分析
shallow cloneは履歴の境界を変える
同じ専門分析は、shallow cloneがコミット履歴を切り詰めると区別する。ファイル内容を後から取得することと、履歴の一部を持たないことは異なる制約だ。現在の状態を一度ビルドする用途と、古い変更を調査する開発環境では必要な履歴が違う。
取得が終わるまでの時間だけでなく、後で行う操作も書き出す。原因調査やブランチの関係確認に十分な履歴があるか、その環境で後続のfetchをどのように使うかを確認する。分析にある環境別の推奨を、すべてのCIや開発環境にそのまま当てはめるべきではない。 履歴のオプション
実際の作業に合わせて組み合わせる
必要なフォルダー数、初回転送、後続のリモート要求、必要な履歴の四項目で目的を整理する。sparse-checkoutとpartial cloneは別の層を減らすため併用を検討できる。ただしビルドツールが選択外のファイルを要求するかも確認する。見える範囲だけで入力がすべて揃ったとは判断できない。
公式文書のsparse indexはインデックス表現を縮める追加の選択で、外部ツールとの互換性検証が必要だ。表示するファイルや取得するオブジェクトとも区別する。既存変更を保存した別環境でエディターとビルドを確認すれば、何が減り、どのリモート依存が残るかを把握しやすい。 インデックス互換性 インストールしたGitの版や外部ツールは現行マニュアルと異なり得る。