Unityプロジェクトのバックアップ、「フォルダごとコピー」でやっていないでしょうか。MyGame_backup、MyGame_0712、MyGame_final_v2_本当に最終……。この方式、いざ「昨日の状態に戻りたい」となった瞬間に、どのコピーが正解か分からなくなります。しかも数GBのコピーが積み重なって、ディスクだけが減っていく。
この記事では、その不安を根本から解決する バージョン管理（Git） をUnityプロジェクトに正しく導入します。Unityには「そのままGitに入れてはいけないフォルダ」や「絶対に無視してはいけないファイル」があり、 最初の設定を知っているかどうかで安全性がまるで変わります。制作規模が大きくなる前——できれば今日——に整えておきましょう。
この記事でわかること
- フォルダコピーのバックアップと バージョン管理 の違い
- 最初に確認するUnity側の2つの設定（Force Text / Visible Meta Files）
- Unity向け .gitignore（Library・Temp・ビルド成果物は入れない）
- .metaをアセットとセットでコミット しないと参照が切れる理由
- 大きいバイナリを Git LFS に預ける基準
- 共同制作で Sceneの競合 を避ける定番ルール
- 実践：ブランチでPrefabを変更し、差分を見て、安心して戻る
動作確認環境: Unity 2022.3 LTS / Unity 6・Git 2.x
バックアップとバージョン管理は別物
フォルダコピーは「ある日の全体を丸ごと保存」です。対してバージョン管理は、 「いつ・何を・なぜ変えたか」を差分の履歴として記録 します。
この違いは、トラブルの日に効きます。
- 戻る場所を選べる: 「動いていた3日前」へ、 コミット単位でピンポイントに戻れる
- 何を変えたか分かる: 「昨日から今日の間に触ったファイル」の一覧と中身の差分が見られる。原因調査の速度が別次元になる
- 容量が増えにくい: 差分だけを記録するので、丸ごとコピーの山より圧倒的に軽い
- 実験が怖くなくなる: ブランチを切れば「試して、ダメなら捨てる」が数秒でできる
Gitそのものの操作（init、commit、push）はUnity固有の話ではないので、この記事では「Unityプロジェクトならではの設定と運用」に絞って進めます。Gitが初めての場合は、GitHub DesktopやForkのようなGUIクライアントから始めると入りやすいです。
最初に確認するUnity側の2つの設定
Gitを使う前に、Unityエディタ側の設定を2つ確認します。場所はどちらも「Edit > Project Settings > Editor」です（Unity 6ではVersion Controlの項目が「Project Settings > Version Control」に分かれています）。
1. Asset Serialization Mode: Force Text
SceneやPrefabの保存形式を テキスト（YAML） にする設定です。テキストであれば、Gitが差分を記録でき、変更内容を目で確認できます。バイナリ形式だと「何かが変わった」ことしか分かりません。
2. Version Control: Visible Meta Files
.meta ファイルをエクスプローラーやGitから見える通常ファイルとして扱う設定です。Gitで管理するための前提になります。
tips: 新しいバージョンのUnityでは、どちらも最初からこの値になっています。それでも一度目で確認しておく価値はあります——もし過去のプロジェクトから設定を引き継いでバイナリ保存になっていると、以降の話がすべて成り立たないからです。
Unity向け.gitignore：入れないものを決める
Unityプロジェクトのフォルダには、 Gitで管理すべきもの と 絶対に入れてはいけないもの が同居しています。仕分けの基準はシンプルで、 「Unityが自動で再生成できるものは入れない」 です。
| フォルダ | Git管理 | 理由 |
|---|---|---|
Assets/ | ✅ | ゲームの中身そのもの（.meta 込み） |
Packages/ | ✅ | 使用パッケージの一覧（manifest.json） |
ProjectSettings/ | ✅ | プロジェクト設定。これが無いと同じ挙動で開けない |
Library/ | ❌ | Unityが再生成するキャッシュ。巨大（数GBになることも） |
Temp/・Logs/・Obj/ | ❌ | 一時ファイル・ログ |
UserSettings/ | ❌ | 個人のエディタレイアウトなど、人ごとに違ってよいもの |
Build/ などビルド成果物 | ❌ | いつでも再ビルドできる出力物 |
.gitignore はプロジェクトのルート（Assets の1つ上の階層）に置きます。最低限、次の内容があれば安全に始められます。
# Unityが自動生成するもの（コミット禁止）
/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Ll]ogs/
/[Uu]serSettings/
/[Mm]emoryCaptures/
# ビルド成果物
/[Bb]uild/
/[Bb]uilds/
*.apk
*.aab
# IDEが生成するもの
.vs/
.idea/
*.csproj
*.sln
注意: 本格的に始めるときは、GitHub公式の gitignoreテンプレート集にあるUnity用 をベースにするのが定番です。上の内容を包含した、より網羅的なリストになっています。
.metaはアセットとセットでコミットする
.gitignore と正反対の注意がひとつあります。アセットごとに自動生成される .meta ファイルは、絶対に無視・削除してはいけません。
.meta の中にはアセットごとの一意なID（GUID）が入っていて、InspectorでのアタッチもPrefabの中身も、ファイル名ではなく GUIDで つながっています。この仕組み自体は プロジェクト整理の記事 で図解しているので、そちらを見てください。Gitの文脈で大事なのは次の2点です。
.metaをコミットし忘れると、他の環境で参照が切れる: 自分のPCでは動くのに、チームメイトがpullするとMissingだらけ——原因の定番が「アセットは上げたのに.metaを上げていない」です。git statusで.metaだけが未追跡のまま残っていないか確認する癖をつけてください- アセットを消すときは
.metaも一緒に消す: アセットだけ消して.metaが残ると、Unityが起動のたびに「中身のないメタ」を警告します。Unityエディタ内で削除すればセットで消えるので、 ファイル操作は原則Unityエディタ内で行う ——これも整理記事と同じルールです
大きいバイナリはGit LFSへ
Gitはテキストの差分管理が得意な仕組みで、 画像・3Dモデル・音声のようなバイナリは苦手 です。バイナリは差分が効かないため、変更のたびにファイル丸ごとが履歴へ積み上がり、リポジトリが際限なく太っていきます。
そこで使うのが Git LFS（Large File Storage） です。LFSの対象にしたファイルは、リポジトリ本体には軽いポインタ（参照カード）だけが入り、実体は別の保管庫に置かれます。
導入は3ステップです。
# 1. LFSを有効化（リポジトリごとに最初の1回）
git lfs install
# 2. LFSに預けるファイルの種類を指定（.gitattributesが作られる）
git lfs track "*.fbx"
git lfs track "*.psd"
git lfs track "*.wav"
# 3. .gitattributesをコミット（このファイルが仕分けルールになる）
git add .gitattributes
git commit -m "Set up Git LFS"
仕分けの目安はこうです。
| ファイル | 置き場所 | 理由 |
|---|---|---|
.fbx・.psd・.wav・.mp4 など大きいバイナリ | LFS | 差分が効かず、サイズも大きい |
.png などのテクスチャ | サイズ次第（大きければLFS） | 小さいアイコン程度なら普通のGitでも可 |
.cs・.md・.json・.asmdef | 普通のGit | テキスト。差分管理の主役 |
Scene・Prefab（.unity・.prefab） | 普通のGit | Force Textでテキスト化済み。差分を見たい |
注意: GitHubには 1ファイル100MB の制限があり、超えるファイルはpush自体が拒否されます。「あとからLFSへ移す」のは履歴の書き換えが必要になって面倒なので、動画や高解像度PSDを扱う予定があるなら 最初からLFSを設定しておく のが安全です。
ひとりでも履歴は効く、ふたりならルールが要る
ひとり開発：まず「戻れる」を手に入れる
個人制作でも、バージョン管理の恩恵は初日からあります。運用はシンプルで構いません。
- 区切りごとにコミットする: 「ジャンプを実装」「敵のHPバー追加」のように、1つの意味のまとまりで記録する。数日分をまとめた巨大コミットは、戻りたい場所を選べなくする
- 壊れそうな実験はブランチで: 「物理演算を全部作り替えてみる」ような賭けは、ブランチを切ってから。ダメだったらブランチごと捨てれば、mainは無傷です
共同制作：同じSceneを同時に触らない
ふたり以上になると、新しい問題が1つ増えます。 同じファイルを同時に編集したときの競合（コンフリクト） です。
C#スクリプトの競合は、テキストなので普通にマージできます。問題は Scene です。Force TextでYAMLになっているとはいえ、Sceneファイルは人間が読むために書かれたものではない巨大な自動生成テキストで、競合を手作業で正しく解決するのはかなり困難です。
だから共同制作の定番ルールは、競合を「解決する」のではなく 「起こさない」 です。
- 同じSceneを同時に触らない: 「今日はAさんがTitle、BさんがStage1」のように、Scene単位で担当を分ける
- Sceneを役割で分割する: 1つの巨大なMainシーンをやめて、UI・ステージ・共通マネージャーを別Sceneにすれば、「同時に触りたい」自体が減ります。分け方は プロジェクト整理の記事 を参照してください
- 共同で触るものはPrefab化する: 敵やギミックを Prefab にしておけば、変更はScene本体ではなく
.prefabという別ファイルに記録されます。担当を分けやすく、競合の単位も小さくなります
実践：ブランチでPrefabを変えて、安心して戻る
最後に、バージョン管理が「保険」から「道具」に変わる体験をひとつ。 「敵を強くしてみたいけど、ゲームバランスが壊れたら怖い」 という日常的な場面を、ブランチでやってみます。
# 1. 実験用のブランチを切る（mainはこの瞬間のまま保存される）
git switch -c tune-enemy-power
# 2. UnityでEnemy.prefabの攻撃力・速度を変更して保存
# 3. 何が変わったかを確認する
git diff Assets/Prefabs/Enemy.prefab
git diff の出力を見てください。Force Textにしてあるおかげで、Prefabの変更がテキストとして見えます。YAMLのすべてを読める必要はありません——それでも m_Speed: 2 が m_Speed: 5 になった行くらいは見つけられるはずで、 「自分が意図した変更だけが入っているか」 の確認にはそれで十分です。
# 4a. 遊んでみて手応えがあれば、mainへ合流
git switch main
git merge tune-enemy-power
# 4b. バランスが壊れていたら、ブランチごと捨てる（mainは無傷）
git switch main
git branch -D tune-enemy-power
Playして確かめてください。合流した場合は強くなった敵がそのまま残り、捨てた場合は 何事もなかったかのように元の敵が立っています。この「失敗してもゼロコスト」の感覚が身につくと、大胆な実験が日常になります。もし git status に見覚えのない大量のファイルが並んだら、.gitignore の仕分けが漏れているサインです——Library/ や Temp/ が混ざっていないか、この記事の表と見比べてみてください。
ポイントは2つです。 mainは常に「動く状態」を保つ（実験はブランチで）。 diffは全部読まなくていい（意図した 変更が入っているかだけ確認する）。
おまけ：先に知っておくと良いこと
- 秘密情報はコミットしない: APIキー、署名用キーストア、サービスの認証JSONなどは、一度コミットすると履歴から消すのが大変です。
.gitignoreに最初から入れておき、万一公開リポジトリへ上げてしまったらキーの無効化・再発行まで行ってください - 有料アセットと公開リポジトリ: Asset Storeなどで購入したアセットは、再配布が禁止されているのが普通です。公開リポジトリに含めるとライセンス違反になり得るので、公開したい場合は購入アセットを除外する構成を検討してください
- SceneのマージにはUnity公式の道具もある: どうしてもScene競合を解決する必要が出たら、Unity付属の UnityYAMLMerge（Smart Merge）をGitのマージツールとして登録する方法があります。ただしこれは最後の手段で、基本は「競合を起こさない運用」が先です
まとめ
- フォルダコピーは卒業。バージョン管理は 「いつ・何を変えたか」の履歴 で、任意の時点へ戻れる
- Unity側の前提は Force Text と Visible Meta Files（新しいUnityではデフォルト）
.gitignoreの基準は 「再生成できるものは入れない」——Library/・Temp/・ビルド成果物は除外.metaはアセットとセットでコミット。忘れると他の環境でMissingになる- 大きいバイナリは Git LFS へ。GitHubの100MB制限に当たる前に設定する
- 共同制作は 同じSceneを同時に触らない——Scene分割とPrefab化で競合を「起こさない」
リポジトリの初期化から最初のコミットまでは、慣れれば10分の作業です。次にプロジェクトを開く前に、その10分を払っておきませんか——「本当に最終」フォルダを、今日で最後にするために。