vendorディレクトリはGit管理すべきか

vendorディレクトリはGit管理すべきか、結論から

結論を先に言ってしまうと、「原則としてはGit管理しない。ただし条件次第では管理する判断も現実的」です。
vendorディレクトリをGitに含めるかどうかは、思想論や宗教論になりがちですが、実際の現場では「環境再現性」「CI/CD」「チーム構成」「依存解決の安定性」といった要素が複雑に絡みます。

多くのプロジェクトでは「依存関係はパッケージマネージャで再現できる」という前提が成り立つため、vendorディレクトリはGit管理から外されます。一方で、オフライン環境や長期保守、外部要因で依存取得が不安定なケースでは、vendorを含める判断が“現実解”になることもあります。

この記事では、vendorディレクトリをGit管理する／しないの判断軸を、具体例と失敗パターンを交えながら整理していきます。

vendorディレクトリとは何かを整理する

vendorディレクトリとは、外部ライブラリや依存パッケージの実体をプロジェクト配下に配置したものです。言語やエコシステムによって多少意味合いは異なりますが、共通しているのは「自分たちが書いていないコードが大量に入る場所」という点です。

たとえば以下のようなケースがあります。

• PHPのComposerで生成されるvendorディレクトリ
• Go Modulesでvendor化した依存コード
• RubyのBundlerでvendor/bundleを使う構成
• JavaScriptでnode_modulesをvendor相当として扱うケース

多くの開発者が最初につまずくのは、「このディレクトリ、Gitに入れるべき？」という疑問です。公式ドキュメントや記事を読むと、ほぼ必ず「Git管理しない」と書かれている一方で、実際の現場では例外が存在します。

Git管理しないとされる理由

vendorディレクトリをGit管理しない理由は、単なる慣習ではありません。技術的・運用的な理由が積み重なった結果です。

リポジトリサイズが肥大化する

vendorディレクトリには数百〜数千ファイルが含まれることも珍しくありません。これをGit管理すると、cloneやfetchのたびに余計なデータ転送が発生します。

特に以下のような状況では問題が顕在化します。

• CIで毎回フルcloneしている
• 複数ブランチを頻繁に切り替える
• モノレポ構成で複数サービスを管理している

Gitは差分管理が得意とはいえ、vendorの更新頻度が高いと履歴も膨れ上がります。

差分レビューが実質不可能

vendorディレクトリを含めると、Pull Requestに大量の差分が表示されます。
しかしその差分は、ほとんどの開発者にとって「読めない」「読む意味がない」ものです。

結果として、

• レビューが形骸化する
• 本来レビューすべき自分たちのコードが埋もれる
• マージ判断が雑になる

といった副作用が起きがちです。

依存関係はlockファイルで管理できる

多くのエコシステムでは、依存関係をlockファイルで固定できます。

• composer.lock
• go.sum
• Gemfile.lock
• package-lock.json / pnpm-lock.yaml など

これらがあれば、vendorディレクトリを含めなくても、同じ依存関係を再現できる設計になっています。この前提がある限り、vendorをGitに含める必要性は低くなります。

それでもGit管理したくなる現実的な理由

理屈では「Git管理しない」が正しくても、現実はそう単純ではありません。

ネットワークに依存したくない

ビルドやデプロイのたびに外部レジストリへアクセスする構成は、以下のリスクを抱えます。

• レジストリ障害でビルド不能
• 社内ネットワーク制限で取得不可
• 過去バージョンが突然取得できなくなる

特にオンプレミス環境や閉域ネットワークでは、vendorを含めることで運用が安定するケースがあります。

長期保守・再現性を最優先したい

数年単位で保守するシステムでは、「当時の依存関係が将来も取得できるか」が不透明です。
lockファイルがあっても、配布元が消滅すれば再現は困難になります。

この場合、「その時点で動いていた依存コードを丸ごと残す」という発想は、決して間違いではありません。

言語・ツールの成熟度が低い場合

エコシステムが成熟していない場合、依存解決が不安定なことがあります。

• lockファイルが完全ではない
• 同一lockでも結果が変わる
• プラットフォーム差異が大きい

こうした状況では、vendorをGit管理した方がトラブルが減ることもあります。

実際にやるとこうなる、失敗しがちなパターン

vendorディレクトリをGit管理して起きがちな失敗も知っておく必要があります。

「とりあえず入れた」が後で足かせになる

初期構築時に勢いでvendorを含めると、後から外すのが非常に面倒になります。

• 履歴に巨大なコミットが残る
• ignore設定を変えても過去は消えない
• チーム内で認識が割れる

結果として、「やめたいけどやめられない」状態に陥りがちです。

CI/CDが想定以上に遅くなる

vendorを含めたリポジトリは、clone時間が伸びます。
CIの実行時間が積み上がると、開発体験に直接影響します。

「依存を毎回installするのと、cloneが遅いのと、どちらがマシか」を冷静に比較しないと、逆効果になることもあります。

判断のためのチェックポイント

vendorディレクトリをGit管理するか迷ったときは、次の観点で整理すると判断しやすくなります。

• 依存関係はlockファイルで安定して再現できるか
• 外部レジストリにどれくらい依存しているか
• ビルドやデプロイはオンライン前提か
• リポジトリサイズ増加を許容できるか
• 数年後に同じ構成を再現する必要があるか

これらに「はい」が多いほど、vendorをGit管理しない判断が自然になります。一方、「いいえ」が多い場合は、vendor管理も選択肢に入ってきます。

代替案という折衷案

Git管理する／しないの二択ではなく、折衷案も存在します。

内部レジストリを立てる

npmやComposer、Go Modulesなどを社内ミラーで運用すれば、外部依存の不安はかなり減ります。
vendorを含めず、かつ再現性も確保しやすい方法です。

アーティファクトとして保存する

vendorディレクトリをGitではなく、ビルド成果物として保存する方法もあります。
リリース時点の依存関係をアーカイブしておくことで、必要なときだけ参照できます。

少しひねったまとめ

vendorディレクトリをGit管理すべきかどうかは、「正解を選ぶ問題」ではなく「どの不便を受け入れるかを選ぶ問題」です。

Git管理しなければ、外部依存や環境差異と向き合う必要があります。
Git管理すれば、リポジトリの重さや運用コストを受け入れる必要があります。

どちらかを完全に避けることはできません。
だからこそ、「自分たちのプロジェクトでは何が一番困るのか」を基準に判断することが、vendorディレクトリ問題で後悔しないための近道だと言えるでしょう。