GitLabとPerforceの二刀流 ―― ゲーム開発現場のリアルな開発フロー

ゲーム開発のバージョン管理というと「Gitで統一すればいいのでは?」と思う人も多いかもしれません。しかし実際の現場、特に3Dアセットや大容量の音声・動画を大量に扱うプロジェクトでは、コードはGitLab、アセットはPerforceという「二刀流」がいまだに根強い定番です。

今回は、この組み合わせが実際どんな流れで運用されているか、現場の雰囲気とその良さを書いてみます。

なぜ2つのツールを使い分けるのか

まず前提として、GitとPerforceは得意分野が違います。

• Git(GitLab):テキストの差分管理が得意。ブランチを切って並行開発し、マージリクエスト(MR)でレビューして統合する、というワークフローに強い。
• Perforce:バイナリファイルの一元管理が得意。ファイル単位のロック(exclusive checkout)ができるので、「このマテリアルファイルは今Aさんが編集中」と衝突を未然に防げる。数百GB〜TB級のリポジトリでも快適に動く。

ゲームのプロジェクトは、コード(C++、C#、シェーダー、ツールスクリプトなど)とアセット(テクスチャ、3Dモデル、音声、動画、レベルデータ)が両方大量にあります。この性質の違うデータを1つのツールで無理に管理しようとすると、どちらかが不便になる。だから役割分担するわけです。

典型的な1日の開発フロー

実際の開発現場でどう回っているか、ある日のエンジニアとアーティストの動きを追ってみます。

朝、エンジニアの場合

1. GitLabで自分のブランチを最新のmain(または develop)にリベース/マージ
2. 前日にレビュー依頼していたMRにコメントが付いていないか確認
3. Issueボードで今日のタスクを確認し、新しいブランチを切って作業開始
4. コード変更をコミット→プッシュ→CI/CDパイプライン(GitLab CI)が自動でビルド&テストを走らせる
5. パイプラインが緑になったらMRを作成し、レビュアーをアサイン

朝、アーティストの場合

1. Perforceクライアント(P4V)を開いて、担当しているアセットのフォルダをSync(最新化)
2. 編集したいテクスチャやモデルファイルをCheckout(ロックを取得)して排他的に編集開始
3. Substance Painterなどのツールでテクスチャを修正
4. 作業が終わったらSubmit(変更をサーバーに反映)し、ロックを解放
5. 必要であればチェンジリストにコメントを添えて、他のメンバーに変更内容を共有

両者が交わる瞬間

エンジニアがUnity/Unrealのプロジェクトファイル自体(シーン、prefabなど)をいじる場合、そこはPerforce側で管理されていることが多く、Gitとは別の作法でロックを取る必要があります。この「切り替え」に慣れるまでは少し戸惑いますが、慣れると自然に手が動くようになります。

現場の雰囲気:良いところ

① コードレビュー文化がしっかり回る

GitLabのMRベースの開発は、プログラマにとって居心地がいいものです。「このロジックはなぜこう書いた?」というレビューコメントのやり取りが自然に発生し、コードの品質が担保されやすい。CI/CDが自動でビルド・テストしてくれるので、レビュアーは「動くかどうか」より「設計や可読性」に集中できます。

② アセットの競合ストレスがない

Perforceのロック機能があるおかげで、「気づいたら誰かと同じファイルを編集していて、マージ地獄に陥った」という事故が起きにくい。アーティストからすると、これは精神衛生上かなり大きいです。Gitでバイナリをマージしようとした経験がある人ほど、Perforceのロックのありがたみが分かります。

③ 役割ごとに最適なツールを触れる安心感

エンジニアはGitLabの世界で、アーティストはPerforceの世界で、それぞれ慣れた作法のまま仕事ができます。無理に片方に寄せていないので、「このツールは自分の職種に合っていない」というストレスが少ない。

④ CI/CDと組み合わせた自動ビルドの心地よさ

GitLab CIでビルドパイプラインを組んでおくと、コードの変更が入るたびに自動的にビルドが走り、Perforce側の最新アセットと組み合わせた実機ビルドまで自動生成、というパイプラインを組んでいるスタジオもあります。朝出社したら夜間ビルドが自動で上がっている、という状態は地味に開発体験を良くします。

一方で、運用上の悩みどころ

良いことばかりではなく、現場でよく聞く悩みもあります。

• 権限管理の二重化:GitLabのアクセス権とPerforceのアクセス権を別々に管理しないといけないので、新しいメンバーのオンボーディング時に設定漏れが起きがち
• 新人の学習コスト:Gitのブランチ感覚に慣れたエンジニアが、Perforceのロック文化に戸惑うことがある(逆も然り)
• どちらにCI/CDのロジックを寄せるか:ビルドパイプラインがGitLab側とPerforce側の両方のデータを参照する場合、依存関係の管理が複雑になりやすい

まとめ

GitLab + Perforceの組み合わせは、「コードはGitの柔軟なブランチ&レビュー文化で」「アセットはPerforceの堅牢なロック管理で」という、それぞれの強みを活かした現実的な選択です。運用コストは多少かかるものの、大容量アセットを扱うゲーム開発においては、今も多くの現場で選ばれている理由がよく分かる組み合わせだと思います。

もし今後、開発チームでツール選定をする機会があれば、「全部Gitに寄せる」のではなく、「データの性質によって適材適所で使い分ける」という発想を持っておくと、後々の運用がぐっと楽になるはずです。