UnityをGitHubで共同開発するための快適な開発環境＋Tips

はじめに

Unityプロジェクトを共同開発するときに、Unityならではの問題が多かったので、快適な共同開発のための開発環境の作り方と開発時のTipsをまとめました。

ソースコードの管理はGitHubを使用します。

GitHubとGitって？

GitHubは開発したソースコードや変更履歴などを管理するためのツールで、自分が書いたコードを他の人に共有したり、逆に他の人が書いたコードを自分のパソコンに取り込んで編集したりできます。
→ つまり、GitHubを使うことで共同開発ができる！
（他にもバージョン管理やCI/CDなど様々な使い方があります）

Gitもソースコードや変更履歴を管理するためのもので、GitHubと連携して使うことが多いです。

簡単に言うと、Gitは自分のパソコンだけでソースコードを管理するもので、共同開発では、そのソースコードをGitHubに上げて他の人と共有しながら開発を進めます。

事前準備

事前準備は公式など分かりやすいサイトがあるので、そちらを参考にしてください。

1. GitHubのアカウントを作成する
   → GitHub でのアカウントの作成 - GitHub Docs
2. PCにUnity Hub・Unityをインストールする
   → Unity Hub をダウンロードする - Unity
3. PCにGitをインストールする
   → Gitのインストール - Git

開発環境の作り方

作業の流れ

以下が作業の大まかな流れです。

1. 代表者がGitHubにリポジトリを作成し、開発メンバーを招待します。
   （コラボレーターを使用します）
2. 代表者がUnityプロジェクトを作成し、開発環境を構築します。（フォルダ構成の決定や.gitignoreの追加など）
3. 作成したUnityプロジェクトをリポジトリにプッシュします。
4. 開発メンバーがリポジトリにあるUnityプロジェクトをローカル（自身のPC）に取り込んで、開発をスタートします。

フォルダ構成

フォルダ構成を決めると、メンバー間で「どのフォルダに何のファイルを入れるか」という共通ルールができるので、ファイルの管理が楽になります。
また、ファイルが増えても、使いたいファイルをすぐに見つけられるので開発効率アップに繋がります。

各フォルダはUnityプロジェクト内で作成します。
Unityプロジェクト内で作成することで、metaファイルが自動で作成されます。

空のフォルダをGitHubに上げたい時はフォルダの中に .gitkeepというファイルを追加することで、Unity側では空フォルダの状態のままで、GitHubにフォルダを上げることができます。
.gitkeepを追加する時は、Unityプロジェクトからではなく、Gitの拡張機能を追加したエディターなどを使用します。

Unityのフォルダ構成は開発するプロジェクトによって異なりますが、私は以下のような構成にすることが多いです。

.
├── Assets/
│   ├── アセットストアなどからダウンロードしたファイル群
│   └── Project/
│       ├── Scenes/
│       │   ├── 本番用シーン
│       │   └── Test/
│       │       ├── Developer1/
│       │       │   └── Developer1のテスト用シーン
│       │       ├── Developer2/
│       │       │   └── Developer2のテスト用シーン
│       │       └── ...
│       ├── Prefabs/
│       │   └── プレハブ化するオブジェクト
│       ├── Scripts/
│       │   └── C#などのスクリプト
│       ├── Animations/
│       │   └── アニメーターコントローラーやモーション
│       ├── Materials/
│       │   └── マテリアル
│       ├── PhysicsMaterials/
│       │   └── 物理エンジンで使用するマテリアル
│       ├── Fonts/
│       │   └── フォント
│       ├── Textures/
│       │   └── テクスチャー
│       ├── Audio/
│       │   └── 音声ファイル
│       ├── Resources/
│       │   └── Resources.Loadで読み込むファイル
│       ├── Editor/
│       │   └── Unityのエディタ拡張用スクリプト
│       └── Plugins/
│           └── ネイティブプラグインなど
└── Packages/
    └── ...

ファイル構成のポイントは、アセットストアなどからインポートしたファイルと、自分たちで開発したファイルを分けることです。

今回の例では、

• Assetsフォルダの中に、Projectフォルダを作成します。

→ そうすることで、アセットストアなどからインポートしたファイルとプロジェクトで開発したファイルを分けることができ、GitHubに外部からダウンロードしたファイルを上げないように設定するのが楽になります。

アセットストアのファイルを別フォルダに入れて、gitignoreする方法もありますが、インポート先のディレクトリは、デフォルトでAssetsフォルダ直下に設定されているので、今回はこのような構成にしています。

• Projectフォルダ内の構成は、Unityフォルダ構成のルールについて - Qiita を参考にしています。

• Scenesフォルダでは、実際のプロダクトで使用する本番用シーンはフォルダ直下に配置します。

  • Developer1、Developr2 ... のフォルダは開発メンバーの名前に変更し、各開発メンバーがスクリプトの動作の確認・テストするためのシーンを自分の名前のフォルダ内に作成して使います。

.gitignoreの作成

.gitignoreとは、GitHubにあげたくないファイルを指定するためのファイルです。

.gitignoreを追加する時は、Unityプロジェクトからではなく、Gitの拡張機能を追加したエディターなどを使用します。

GitHubで用意されているUnity用の.gitignoreテンプレートに、アセットストアのファイルを無視する設定を追加します。

.gitignore

/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/[Ll]ogs/
/[Uu]ser[Ss]ettings/

# MemoryCaptures can get excessive in size.
# They also could contain extremely sensitive data
/[Mm]emoryCaptures/

# Recordings can get excessive in size
/[Rr]ecordings/

# Uncomment this line if you wish to ignore the asset store tools plugin
# /[Aa]ssets/AssetStoreTools*

# Autogenerated Jetbrains Rider plugin
+/[Aa]ssets/Project/Plugins/Editor/JetBrains*

# Visual Studio cache directory
.vs/

# Gradle cache directory
.gradle/

# Autogenerated VS/MD/Consulo solution and project files
ExportedObj/
.consulo/
*.csproj
*.unityproj
*.sln
*.suo
*.tmp
*.user
*.userprefs
*.pidb
*.booproj
*.svd
*.pdb
*.mdb
*.opendb
*.VC.db

# Unity3D generated meta files
*.pidb.meta
*.pdb.meta
*.mdb.meta

# Unity3D generated file on crash reports
sysinfo.txt

# Builds
*.apk
*.aab
*.unitypackage
*.app

# Crashlytics generated file
crashlytics-build.properties

# Packed Addressables
/[Aa]ssets/[Aa]ddressable[Aa]ssets[Dd]ata/*/*.bin*

# Temporary auto-generated Android Assets
/[Aa]ssets/[Ss]treamingAssets/aa.meta
/[Aa]ssets/[Ss]treamingAssets/aa/*

+# Asset Store files
+/[Aa]ssets/*
+!/[Aa]ssets/Project/

開発時のTips

パッケージの追加

（パッケージは [Window] > [Package Manager] から追加できます）

Unityでは、Packages/manifest.jsonとPackages/packages-lock.jsonを元に、パッケージが管理されています。

例えば、Aさんが新しいパッケージを追加すると、これらのファイルにパッケージが追加されたということが記述されます。
そして、Bさんがその変更を受け取ると、BさんのUnityプロジェクトでもAさんが追加したパッケージが自動的に追加される仕組みになっています。

この仕組みによって共同開発でのパッケージ管理が便利になっているのですが、複数人が同時にパッケージを入れると、Packages/manifest.jsonとPackages/packages-lock.jsonが同時に書き変わるので、コンフリクトが起きたり、パッケージのバージョンが書き変わる可能性があります。

そこで、パッケージを追加するときは、メンバー間でコミュニケーションを取ったり、パッケージを追加する人を決めたりするのがおすすめです。

外部からインポートするパッケージ（ [Assets] > [Import Package] > [Custom Package] から追加するもの）に関しては、他メンバーには共有されないので、各自でインポートします。

シーンの変更

Unityで変更したシーンをGitHubからコードベースで見ると、このようなコードになっています。

SampleScene.unity

%YAML 1.1
%TAG !u! tag:unity3d.com,2011:
--- !u!29 &1
OcclusionCullingSettings:
  m_ObjectHideFlags: 0
  serializedVersion: 2
  m_OcclusionBakeSettings:
    smallestOccluder: 5
    smallestHole: 0.25
    backfaceThreshold: 100
  m_SceneGUID: 00000000000000000000000000000000
.
.
.

これでは、シーンの何が変更された分かりにくく、プルリクにシーンの変更が入っているとレビューが難しくなってしまいます。

また、複数人が同じシーンを同時に編集するとコンフリクトが起きて、作業が中断してしまいます。

なので、共同開発では本番用シーンは編集する人を１人に決めて作業することがおすすめです。

コミット時の注意

開発中、自分では変更していないファイルが勝手に変更されているケースがよくあります。
それに気づかずコミットしてしまうと、コンフリクトが起きたり、レビュー時に担当者を困惑させることになります。

これを避けるために、コミット前にgit statusなどで、どのファイルが変更されたか確認するようにしましょう。

文字コード

Visual Studioで開発していると、OSによって文字コードが異なるので、メンバーが異なるOSを使っているとコメントアウトが文字化けしてしまいます。
なので、Visual Studioの文字コードの設定を全員で統一するようにしましょう。

Macでは以下から文字コードを変更することができます。

参考リンク

• Unity開発者が複数人で開発を進める上で覚えておくと幸せになる９つの事 - Hatena Blog
• Unityフォルダ構成のルールについて - Qiita