「Unityでチーム開発を始めたいけど、Gitって何を設定すればいいんだろう」「なんとなくGitは使っているけど、シーンファイルが壊れないか不安」——そんな悩みを抱えていませんか。
Unityのプロジェクトは、シーンやPrefabの保存形式が独特なうえ、画像や音声といった大きなファイルも扱うので、一般的なGitの使い方だけではうまくいかないことがあります。
この記事では、Unityプロジェクトを安全にGit管理するための設定手順から、チームで作業してもコンフリクトが起きにくい運用ルールまで、順番に解説していきます。
UnityでGit管理を始める前にやる設定
Unityプロジェクトをこれからgitで管理していくなら、まず最初にUnityエディタ側の設定を見直しておく必要があります。この設定をせずにGitを使い始めてしまうと、あとから差分がうまく取れなかったり、ファイルの中身がバイナリのまま扱われてしまったりするんです。
難しそうに聞こえるかもしれませんが、実際はUnityの設定画面から2箇所を切り替えるだけなので、そこまで身構えなくても大丈夫ですよ。
Visible Meta FilesとForce Textの設定手順
まずは、Unityの設定を「Gitで扱いやすい形式」に変更していきましょう。手順は以下の通りです。
- Unityのメニューバーから「Edit」→「Project Settings」を開く
- 設定ウィンドウの左側にある「Editor」タブを選択する
- 「Version Control」の項目にある「Mode」を
Visible Meta Filesに変更する - 「Asset Serialization」の項目にある「Mode」を
Force Textに変更する
この設定は、プロジェクトを新規でGit管理する場合はもちろん、既存プロジェクトを途中からGit管理に切り替える場合も、できるだけ早い段階でやっておきたい設定です。
この設定を後回しにしたまま作業を進めてしまうと、途中でファイル形式が切り替わり、余計な差分が大量に発生することがあります。Gitを使い始める前に済ませておくのがおすすめです。
なぜこの設定が必須なのか
そもそもUnityは、初期状態だとシーンやPrefabの一部をバイナリ形式で保存していて、これはGitが差分を読み取るのが苦手な形式なんです。Force Textにしておくことで、変更内容がテキストとして記録され、誰が何を変えたのか追いやすくなります。
また、Visible Meta Filesにしておくと、アセットとひもづく.metaファイルがエクスプローラー上でも見える状態になります。
次にくわしく説明しますが、この.metaファイルこそがUnityのGit管理でいちばん注意が必要な存在なんです。
Unity向け.gitignoreの書き方
Unityでgit管理をするうえで、いちばん気になるのが「何を.gitignoreに書けばいいのか」という点だと思います。Unityは自動生成されるフォルダやファイルが多いので、全部をコミットしてしまうとリポジトリがあっという間に重くなってしまうんです。
ここでは、除外すべきものと、逆に残しておくべきものを分けて説明していきますね。
除外すべきフォルダ一覧
まずはプロジェクトのルートフォルダに.gitignoreというファイルを作成しましょう。中身は、Unity公式やGitHubで配布されている「Unity用.gitignoreテンプレート」をベースにするのが手堅い方法です。
代表的な除外対象は、次のようなフォルダです。
[Ll]ibrary/(Unityが自動生成するキャッシュフォルダ)[Tt]emp/(一時ファイル用フォルダ)[Oo]bj/(ビルド時の中間ファイル)[Bb]uild/(書き出したビルドファイル)UserSettings/(個人のエディタ設定)
これらはどれも「そのPC上で自動的に再生成できるもの」という共通点があります。逆にいうと、消えても誰も困らないファイルなので、Gitで管理する必要がないんです。
フォルダの整理という意味では、アセット自体の置き場所やファイル名のルールを決めておくと、除外設定もさらにスッキリします。あわせて読んでおくと、プロジェクト全体の見通しがよくなりますよ。
追跡すべきファイルの見分け方
基本的には除外対象を増やしていく作業になりますが、一部は「除外したくないファイル」も出てきます。たとえば.metaファイルや、ProjectSettings/フォルダの中にある.assetファイルは、プロジェクト全体で共有すべき大事な設定なんです。
もし.gitignoreの書き方によってこれらまで除外対象に入ってしまった場合は、ファイルの先頭に!をつけることで、追跡対象として明示的に指定できます。
!ProjectSettings/*.assetこんなふうに書いておけば、意図せず大事な設定ファイルまで除外してしまう事故を防げます。
既に追跡済みのファイルを後から除外する方法
ここで一つ、勘違いしやすいポイントがあります。.gitignoreに書いても、すでにコミット済みのファイルはそれだけでは除外されません。.gitignoreが効くのは、あくまで「まだGitに登録されていないファイル」に対してだけなんです。
もしLibraryフォルダなどを誤って先にコミットしてしまっていた場合は、次のコマンドでキャッシュから削除してあげる必要があります。
- ターミナルでプロジェクトのルートフォルダに移動する
git rm -r --cached Library/のように、対象フォルダをキャッシュから削除するコマンドを実行する- その後、通常通り
git add .gitignoreとgit commitで変更を記録する
--cachedをつけることで、Gitの管理対象からは外れますが、PC上の実ファイルはそのまま残ります。うっかり実ファイルまで消してしまわないよう、オプションの付け忘れには気をつけてくださいね。
.metaファイルは絶対に削除しない
Unityのプロジェクトフォルダを見ていると、アセット一つひとつに対して同じ名前の.metaファイルがくっついていることに気づくと思います。一見「複製されたゴミファイル」のように見えてしまうんですが、これを不要だと判断して削除・除外してしまうのは避けたいところです。
ここでは、.metaファイルが何のためにあるのか、そして扱いを間違えるとどうなるのかを説明していきますね。
.metaファイルの中には、そのアセットに割り当てられたGUID(一意のID)が記録されています。UnityはファイルパスやファイルはなくGUIDを頼りにアセット同士の参照関係を管理しているので、このIDが失われると、シーンやPrefabがどのアセットを使えばいいのか分からなくなってしまうんです。
.metaファイルを削除したり、Gitの管理対象から除外したりすると、シーン内のオブジェクトが「Missing」表示になり、アタッチしていたスクリプトや画像が外れてしまうことがあります。一度失われたGUIDのひもづけは、手作業での復旧が難しいケースも多いです。
特に注意したいのが、エクスプローラー(Windows)やFinder(Mac)から直接アセットを操作してしまうケースです。アセットのファイル名を変更したり、フォルダを移動させたりすると、対応する.metaファイルが置き去りになってしまうことがあります。
こうしたトラブルを避けるには、アセットの移動・リネーム・削除は、できるだけUnityエディタの「Project」ウィンドウ上で行うのがおすすめです。
エディタ上で操作すれば、Unityが自動的に.metaファイルも一緒に追従してくれるので、GUIDのひもづけが壊れる心配がありません。
大容量アセットはGit LFSで管理する
Unityのプロジェクトには、テクスチャや音声、3Dモデルといった容量の大きいファイルがたくさん含まれます。これらをそのままGitで管理し続けると、リポジトリがどんどん重くなり、クローンやpullに時間がかかるようになってしまうんです。
そこで役立つのがGit LFS(Large File Storage)という仕組みです。大容量のバイナリファイルを別の場所に保存し、Gitリポジトリ自体は軽い状態を保ってくれます。
導入を検討すべきタイミング
とはいえ、すべてのプロジェクトに最初からLFSが必要というわけではありません。目安として、リポジトリ全体のサイズが数百MBを超えてきたあたりから、pullやpushに時間がかかっているように感じ始めたら、導入を検討してもいい頃合いだと思います。
逆に、テキストベースのスクリプトが中心で、画像や音声がまだ少ないプロジェクトであれば、無理に急いで導入しなくても困らないケースが多いです。
Git LFSの導入手順
実際にGit LFSを使う場合は、以下の手順で設定していきます。
- ターミナル(またはコマンドライン)で
git lfs installを実行し、Git LFSを初期化する git lfs track "*.png"のように、LFSで管理したいファイルの拡張子を指定する(画像・音声・動画など、容量の大きくなりやすい拡張子ごとに指定していきます)- 上記の操作によって生成された
.gitattributesファイルを、git add .gitattributesで追加してコミットする
この手順を踏んでおくと、指定した拡張子のファイルは以降、自動的にLFS側で管理されるようになります。
すでにコミット済みの大容量ファイルは、あとから
git lfs trackを設定しても自動では軽量化されません。既存の履歴ごと整理したい場合は、履歴の書き換えが必要になるため、対応前にチーム内で影響範囲をよく確認しておくと安心です。
シーン・Prefabのコンフリクトを防ぐ
複数人でUnityを触っていると、一番怖いのが「シーンやPrefabを同時に編集してしまい、片方の変更が消えてしまう」というコンフリクトだと思います。テキストのコードと違って、シーンファイルは中身が複雑なので、Gitの標準的なマージ機能だけでは自動で解決しきれないことが多いんです。
ここでは、コンフリクトを減らすためのツール設定と、頻発してきたときの見極め方を紹介します。
UnityYAMLMerge(スマートマージ)の設定手順
Unityには、シーンやPrefabのコンフリクトをある程度自動で解決してくれるUnityYAMLMergeというツールが標準で同梱されています。これを設定しておくと、単純な変更であれば手作業でのマージ作業を減らせます。
- Unityのインストールフォルダ内から、UnityYAMLMergeツールの場所を確認する
- 使用しているGitクライアント(SourceTreeやコマンドラインなど)の設定ファイルを開き、外部マージツールとしてUnityYAMLMergeのパスと実行時の引数を登録する
- Unityの「Project Settings」→「Version Control」内にある「Smart Merge」の項目を有効にし、「Premerge」または「Ask」を選択する
設定ファイルの記述方法は使っているGitクライアントによって多少異なるので、詳しい書き方はお使いのツールの公式ドキュメントもあわせて確認しておくと安心です。
コンフリクトが頻発するときに見直すべきこと
スマートマージを設定していても、複数人が同じシーンを長時間触り続けていると、コンフリクトが頻発してしまうことがあります。そんなときは、ツールの設定だけで解決しようとせず、作業のやり方自体を見直すサインだと捉えてみてください。
目安として、次のような状態に当てはまるかどうかをチェックしてみましょう。
- ✅ 同じシーンファイルを複数人が同時に開いて作業している
- ✅ 1つのシーンにUI・敵キャラ・ギミックなど、役割の違う要素が全部詰め込まれている
- ✅ 誰がどの部分を担当しているのか、事前に決まっていない
これらに複数当てはまる場合は、シーンを機能ごとに分割したり、編集頻度の高い要素をPrefab化して切り出したりすることで、同時編集そのものを避けやすくなります。
次に紹介する担当分けのルールも、あわせて意識しておくとよいと思います。
チーム開発で決めておくべき運用ルール
ツールの設定を整えても、チームメンバーそれぞれの作業の進め方がバラバラだと、トラブルは起きやすくなってしまいます。ここからは、Gitやシーン設定とあわせて決めておきたい、人側の運用ルールを紹介していきますね。
Unityバージョンの統一
意外と見落とされがちなんですが、チームメンバーの間でUnityのバージョンがバラバラだと、マイナーバージョンの違いだけでもシーンの挙動が変わったり、最悪の場合ファイルが壊れてしまったりすることがあります。
プロジェクトを開く前に、全員が同じUnityバージョンを使っているか確認する習慣をつけておくのがおすすめです。プロジェクトフォルダ内にあるProjectVersion.txtをGitで管理しておけば、そのプロジェクトが本来どのバージョン用に作られているのか、誰でもすぐに確認できます。Unity Hubを使えば、指定したバージョンでプロジェクトを開くよう固定することも可能です。
ブランチ戦略とコミットルール
作業ブランチの運用も、事前にルールを決めておくとコンフリクトが起きにくくなります。よく使われるのは、リリース用のmain、開発用のdevelop、機能追加ごとのfeatureブランチを使い分けるやり方です。
ここで気をつけたいのが、feature ブランチを長期間放置しないことです。作業ブランチが長く残っていればいるほど、develop側との差分が大きくなり、あとでマージするときのコンフリクトも大きくなってしまいます。区切りのいいタイミングで、こまめにdevelopへマージしていくのが安全です。
コミットメッセージについても、feat: ○○を追加やfix: ○○を修正のように、変更の種類が分かるプレフィックスをつけておくと、あとから履歴を追うときにとても助かります。「調整」「修正」だけのような、何をしたのか分からないメッセージは避けたいところです。
コンフリクトを防ぐ担当者・シーン分割の決め方
前の見出しでも触れた通り、シーンやPrefabの同時編集はコンフリクトの大きな原因になります。これを防ぐには、誰がどの部分を担当するのか、作業に入る前に決めておくことが効果的です。
プロジェクトの規模がある程度大きくなってきたら、フォルダ構成や命名規則をチーム内でそろえておくことも、担当分けをスムーズにするうえで役立ちます。
また、コンフリクトを未然に見つけるという意味では、CI(継続的インテグレーション)環境を使って、pushのたびにビルドやチェックを自動で走らせる仕組みを取り入れているチームもあります。手作業での確認漏れを減らしたい場合は、こうした自動化もあわせて検討してみるとよいと思います。
ファイルパスの長さにも注意
もう一つ、地味だけど見落としやすいのがファイルパスの長さです。Windows環境では、パスの文字数が255文字を超えるとエラーが発生しやすくなります。
フォルダの階層を深くしすぎず、ファイル名もできるだけ短くしておくと、こうしたトラブルを避けやすくなります。
Git管理とUnity Version Controlどちらを選ぶか
ここまでGitでの管理方法を中心に解説してきましたが、Unityには公式のバージョン管理サービスとしてUnity Version Control(旧Unity Collaborate)という選択肢もあります。どちらを選ぶべきか迷っている場合は、チームの規模や求める柔軟性で判断してみてください。
それぞれの特徴を簡単に比較すると、次のようになります。
| Git | Unity Version Control | |
|---|---|---|
| 向いている規模 | 個人〜大規模チームまで幅広く対応 | 小〜中規模のチームで手軽に始めたい場合 |
| 導入の手軽さ | .gitignoreなど初期設定がやや必要 | Unity内から比較的簡単に始めやすい |
| ブランチ運用の柔軟性 | 細かいブランチ戦略を組みやすい | Gitほど複雑な分岐運用には向きにくい |
| 他ツールとの連携 | GitHub・GitLabなど幅広く連携可能 | Unityエコシステム内での連携が中心 |
個人開発や、まずは手軽にバージョン管理を試してみたいという場合は、Unity Version Controlから始めても困らないと思います。一方で、細かいブランチ運用をしたい場合や、GitHub上でのコードレビュー・CI連携なども見据えているなら、この記事で紹介してきたGitでの管理が力を発揮しやすい場面が多いです。
どちらか一方に決めきれないという場合は、まずは小さいプロジェクトでGitを試してみて、.gitignoreや.metaファイルの扱いに慣れてから本格的なチーム開発に持ち込む、という進め方も一つの手だと思います。
よくある質問
-
QWindowsとMacが混在するチームでも、改行コード(CRLF/LF)の設定は必要ですか？
-
A設定しておくのがおすすめです。WindowsとMacでは改行コードの扱いが異なるため、そのままにしておくと、実際には変更していない行まで差分として表示されてしまうことがあります。
.gitattributesに* text=autoのような設定を追加しておくと、Git側で改行コードを自動的にそろえてくれるので、余計な差分に悩まされにくくなります。すでにチーム開発を始めている場合は、早い段階で統一しておくと後々の見づらさを防げます。
-
Q.gitignoreの設定が漏れて大きいファイルを既にコミットしてしまった場合、後から履歴ごと軽くできますか？
-
A履歴を書き換えることで軽量化できる場合はありますが、簡単な作業ではありません。BFG Repo-Cleanerのようなツールを使えば、過去のコミット履歴から不要な大容量ファイルを取り除くことは可能です。ただし履歴そのものを書き換える操作になるため、チームメンバー全員のリポジトリに影響が出てしまいます。作業前には必ずチーム内で共有し、バックアップを取ったうえで進めるようにしてください。
-
Q個人開発の小規模プロジェクトでも、ここまでのGit管理は必要ですか？
-
Aプロジェクトの規模や今後の予定によって判断してよいと思います。一人で完結する小さなプロジェクトであれば、Git LFSやスマートマージの設定までは急いで整えなくても困らないケースが多いです。一方で、.gitignoreと.metaファイルの扱いだけは、後からチーム開発に発展したときの手戻りを防げるので、早い段階からやっておくと安心です。
※当サイトはアフィリエイト広告を利用しています。リンクを経由して商品を購入された場合、当サイトに報酬が発生することがあります。
※本記事に記載しているAmazon商品情報（価格、在庫状況、割引、配送条件など）は、執筆時点のAmazon.co.jp上の情報に基づいています。
最新の価格・在庫・配送条件などの詳細は、Amazonの商品ページをご確認ください。