Unreal Engine に Git は向いてない
Unreal Engine に Git は向いてない
どうすればいいのか
ヨウネンキ合同会社 石川 (すとんりばー)
聞いたことはありませんか
Unreal Engine に Git は向いていない
私もそう思います
Unreal Engine に Git は向いていない
私もそう思います
でも、なぜそう言われるのか？
UE x Git のここがダメ
- UE のアセット入れるとダメ
- 転送速度がダメ
- ブランチでコンフリクトしてダメ
- UE サポートがダメ
- そもそも他と比べてムズくてダメ
じゃあ UE x Git はだめか……
いいや
ダメと決めつけるにはまだ早い
ダメ の原理を掘り下げて UE x Git がどう根本的にダメなのか理解しましょう
ちょっとわかる UE x Git のダメ
- 履歴の肥大しやすさ
- ブランチとの相性の悪さ
- UX / ツールの弱さ
- UE のアセット入れるとダメ
- 転送速度がダメ
- ブランチでコンフリクトしてダメ
- UE サポートがダメ
- そもそも他と比べてムズくてダメ
- 履歴の肥大しやすさ
- ブランチとの相性の悪さ
- UX / ツールの弱さ
- UE のアセット入れるとダメ
- 転送速度がダメ
- ブランチでコンフリクトしてダメ
- UE サポートがダメ
- そもそも他と比べてムズくてダメ
- 履歴の肥大しやすさ
- ブランチとの相性の悪さ
- UX / ツールの弱さ
- UE のアセット入れるとダメ
- 転送速度がダメ
- ブランチでコンフリクトしてダメ
- UE サポートがダメ
- そもそも他と比べてムズくてダメ
- 履歴の肥大しやすさ
- ブランチとの相性の悪さ
- UX / ツールの弱さ
- UE のアセット入れるとダメ
- 転送速度がダメ
- ブランチでコンフリクトしてダメ
- UE サポートがダメ
- そもそも他と比べてムズくてダメ
履歴の肥大しやすさ
- Git は大きいファイルに向いてない！
- プロジェクトのサイズが膨れ上がる！
よく聞きます。
UE でよく使われる Git 以外の VCS は、ざっくりこういうデータの管理方法をする。
Git はこうです。
※ 本来のGitには明確な「サーバー」は存在しないのですが、許してください
Git はユーザーの手元だけでも完結したシステム。 サーバーが落ちていても履歴を記録できる。
→ その代償にすべての履歴をフルサイズで抱えることに。
ブランチとの相性の悪さ
Git を代表する機能であるブランチ
他の人の影響を受けない世界で作業をして、あとから成果を統合するフローが一般的
たとえファイルがぶつかっても大丈夫
互いの変更をマージしていけばいい！
ところが残念
UE のアセットは原則マージできない
そもそも差分がとれない
※ UE Editor 上で見られるごく一部を除く
UX / ツール
- Git 固有の概念が難しく、チーム開発ではサポートコストが高い
- UE と組み合わせて便利なツールが少ない
ていうか EpicGames が Git 使ってない
公式ツールの対応度が低い
エンジンに入ってる Git Plugin の見捨てられ感
ドキュメントに輝く「このツールはPerforce専用です」の文字
※仕方ないこと
じゃあ Git はお手上げ？
じゃあ Git はお手上げ？
いいえ Git もちゃんと考えてはいる。
履歴の肥大しやすさへの対策
操作時、コマンドにオプションを設定することができる。
- blobless clone — 履歴上のファイルは必要になるまで
--filter=blob:none
- shallow clone — 取得する履歴の深さを限定
--depth=1
- sparse checkout — 一部ディレクトリだけ
git sparse-checkout set <dir>
- Git LFS — 大容量ファイルを履歴の外に
- 次ページで詳しく
Git LFS で大容量ファイルを履歴の外に
Git LFS は要するにこういうこと。履歴に埋め込まず、必要なときだけ取得する。
Git LFS の沼
- 大手サービスの LFS サーバーは高い
- その割に転送速度はあまり速くない
- 転送量で従量課金されることも多い
- かといって自前で立てるのも運用コストが高い
- Git の機能ではなく、外側で頑張って実装されている
- Git の操作の外側なので、操作に失敗するとフォルダの状態が壊れがち
- LFS にちゃんと対応しているGUIクライアントはほとんどない
ブランチとの相性の悪さへの対策
LFS lock — Git にロック機能を追加
LFS lock の闇
この図、もしこうロックしたらどうなるでしょう？
LFS lock の闇
安全にするためのロックを、安全に使うための運用ルールが生えがち
UX / ツールへの対策
Git のいいところ。 オープンソースで普及率が高く、第三者の優秀なツールがたくさんある。
- UEGitPlugin — UE Editor 上で Git 操作をする。公式よりは良い。
- 多種多様な Git クライアント — GUI ツールもコマンドラインツールも、たくさんある。
良くも悪くも「自分で用意して使う」文化
どうすれば UE でも Git を快適に！？
どうすれば UE でも Git を快適に！？
通常取得時は --filter=blob:none を指定。
どうすれば UE でも Git を快適に！？
通常取得時は --filter=blob:none を指定。
CI など頻繁な取得ではコスト削減のため--depth=1 や --sparse。
大容量バイナリがあれば Git LFS サーバーを用意し、 gitattributes を調整した上でロック運用を開始、安全なロック管理のためのGit hookやルール整理、UE には衝突回避のState Branchを設定しておきます。
チームメンバーが複雑な操作に迷わないよう、定型操作はバッチファイル化しておくとさらに良いですね。
uasset の中身は…まあ、あきらめましょう。他のVCSも uasset は見られません。
これで……
UE でも Git が……
快適に……？
できはするかもしれないが、 夢が Git 職人かインフラエンジニアの方以外には あまりおすすめできません。
ではなぜ Git は使われるのか？
UE で Git を使う人はたくさんいる
特に、コミュニティやインディー、ノンゲーム分野から UE に来たチームには多い。
UE の外では
Git は デファクトスタンダード。 以下はプロの開発者向けに取られた大規模アンケートの結果。
ここまで普及した Git は今や
あらゆるツールを使うための
フォーマット・プロトコル
となっている側面がある
昨今の
GitHub / CI/CD ツール / チケット管理 / レビューツール / IDE 統合 / セキュリティスキャン / AI コーディングツール
みんな Git 前提でエコシステムが提供されている
だから使われる
UE との相性問題さえなければ、 運用的にも金銭的にも低コスト
- ノンゲームから UE に来たチーム
- もともと Git 文化圏
- リソースの少ない小規模チーム
- サーバーを用意しなくてもチームで使い始められる
やっぱり UE でも Git を快適に使いたい！
業界の中から見ると見えにくいですが、そう思っている人は結構いるはずです。 わたしもその一人です。
でも……
通常取得時は --filter=blob:none を指定。
CI など頻繁な取得ではコスト削減のため--depth=1 や --sparse。
大容量バイナリがあれば Git LFS サーバーを用意し、 gitattributes を調整した上でロック運用を開始、安全なロック管理のためのGit hookやルール整理、UE には衝突回避のState Branchを設定しておきます。
チームメンバーが複雑な操作に迷わないよう、定型操作はバッチファイル化しておくとさらに良いですね。
uasset の中身は…まあ、あきらめましょう。他のVCSも uasset は見られません。
で、これ誰がメンテするの？
うち(弊社)で作ってみました
Real Git, for Unreal Engine
Real Git, for Unreal Engine
Textil ってどんなもの？
Git と UE の相性もないを解決するために、Git 本体にまで手を入れて作った UE 向け Git クライアントです。要するに、ここまで話してきた UE x Git のつらさをだいたいすべて解決することを目指した製品です。
ただの Git LFS 対応 クライアントじゃない
Unreal C++ を読み込んでデータ型を把握し、uasset の値を差分表示したり、アセットのサムネイルやノードグラフを見せたりしてくれます。 Editor 向けのプラグインも提供していて、UE 標準の Revision Control 機能と同等以上の操作にアクセスすることができます。
便利な UI なだけでもない
Fork(改造)した Git を内蔵し、標準Git や LFS に完全な互換性を持ちつつ、より安全にバイナリをローカルで管理できる独自実装を備えています。
ただの LFS クライアントとして使うだけでも、通常の LFS 実装よりも安全で、プロジェクトの状態が壊れにくくなっています。
サーバーも提供します
大容量バイナリ管理保存のための、 Textil 専用のバイナリサーバーも提供します。
Textil Cloud は GitHub の代替品ではありません。GitHub などでプロジェクトを管理したまま、重たいファイルだけを Textil Cloud に保存できます。
また、Textil Cloud は、Git LFS の Lock とは別の、より強力なロック機構を提供します。
クローズドテスト参加者募集中
いますぐ DL してお試しください！と言いたいところですが、現在はクローズドベータテストを実施中です。
ご興味ある方は、ぜひクローズドテストにご参加ください！
Closed Test: https://textil.dev
さいごに
Textil に少しでも興味を持っていただけたなら嬉しいです。
ただ、一度だけでも、Git職人として最強のGit環境を作ることに挑戦してみたのなら、UE x Git のことをより深くしることができるかもしれません。
おわり