はじめに

カヤックのソーシャルゲーム事業部で働いているUnityエンジニアのmadaです。
カヤックでは、Unityのプロジェクトのバージョン管理にGit、ホスティングサービスにGithubを利用しています。今日はGitでUnityプロジェクトを管理する方法について紹介します。

この記事はカヤックUnityアドベントカレンダー2016の22日目の記事です。

UnityプロジェクトのGit管理について

プロジェクトをGitで管理する際、AssetsとProjectSettingsディレクトリを含める必要があります。LibraryとTempディレクトリは含めなくても動作に影響はありません。 Gitの管理対象から外したいディレクトリやファイルは.gitignoreに記述します。 .gitignoreの例を紹介します。

Library
Temp
*.bat
*.csproj
*.csproj.user
*.booproj
*.pidb
*.sln
*.sln.meta
*.suo
*.unityproj
*.userprefs
*.userprefs.meta
*~
.DS_Store
*[! -~]*
*.pidb.meta

metaファイルについて

UnityではAssets以下のコンテンツを内部のゲームにすぐに使えるデータに変換して、プロジェクトのLibrary以下に保存しています。 Assets以下にはインポートしたファイルがそのまま残ります。例えばテクスチャのインポート設定でTextureFormatを上書きすると、 Assets以下のテクスチャは上書かれずにLibrary以下のファイルが上書きされています。

Library以下に格納するための設定はmetaファイルに保存されます。 metaファイルにはアセット固有のIDと、インスペクターに表示されるインポート設定が保存されています。

詳しくは公式のマニュアルを参照してください。
アセットの内部処理

Gitでmetaファイルを管理する

metaファイルに記述されたインポート設定もGitでバージョン管理するために以下の設定をします。 metaファイルはテキスト形式で管理したほうが、差分の設定がわかるので便利です。

Edit->Project Settings->Editorから Version Control: Visible Meta Files Asset Serialization: Force Text

Gitにおける大文字と小文字の区別

Gitでは、標準で大文字と小文字のファイル名が区別されません。同じファイル名で、大文字と小文字を変更するだけでは差分が認識されません。 Gitで同じファイル名の大文字と小文字を変更するときは以下のコマンドが利用できます。

git mv -f Readme.md README.md
-f Force renaming or moving of a file even if the target exists

Gitにおける空ディレクトリの扱い

Gitでは空のディレクトリは管理されませんが、 Unityは空のディレクトリでもmetaファイルを作成します。そのためmetaファイルだけコミットされ、対象のディレクトリは存在しないケースが生じます。このようなケースを避けるために、ディレクトリを新規作成すると、 .gitkeepという空のファイルを自動配置するPostProcessを作成し利用しています。

文字コードと改行コード

それぞれの開発環境で文字コードや改行コードが異なると無駄な差分が発生するので、プロジェクト内で統一したほうが良いです。文字コードは日本語を利用するためBOM付きUTF-8、改行コードはWindows形式のCRLFで統一しています。

Git-Flow

Gitを用いて効率的に開発を行うフローにGit-Flowというモデルがあります。カヤックのプロジェクトでは、このフローに基づいて開発を行っています。詳しくは以下のページを参照してください。
git-flow-cheat-sheet

コードレビュー

機能開発が完了したブランチをマージする時は必ず他人にコードレビューしてもらいます。コードレビューによってバグを生むコードを発見したり、他人のコードをよく読むことで勉強にもなります。

GitのホスティングサービスにGithubを利用しているため、 Pull Request上でレビューを行いコメントを残しています。

現在のプロジェクトで、レビュー時に注意している項目をまとめてみました。

わかりやすさ
メンテナンスしやすさ
コーディング規約が順守されているか
スペルミスがないか
共通できるコードを共通化しているか
コードのカップリング度が低いか
命名の一貫性があるか
データの処理はモデルに書いているか
メソッド名と実装がかみ合っているか
マジックナンバー使ってないか
無駄にコメントアウトされたコードが残っていないか
ファイル配置が正しいか
ロジックに問題がないか
Warningが出てないか
無限ループから抜け出せなくなってないか
null になりそうな項目が null チェックされているか
配列へのアクセス時に配列の長さとのチェックをしているか
SaveProject を実行して差分がでないことを確認（BuildSettingsなど）
Update()、LateUpdate() 中での参照が、キャッシュされているか
Update()、LateUpdate() 内で foreach を利用していないか
GameObject.Find を利用してオブジェクトを取得していないか
空の文言は "" ではなく string.Empty を使う
動的に変更を想定していない値には readonly が設定されているか
型変更時、型変更されることが確実ならキャスト、不確実ならば as を利用しているか
不要なファイルコミットしてないか

Pull Requestの活用紹介

Unityでスマートフォン用の実機ビルドを用意するのには10分以上の時間がかかることもあります。開発者の環境で実機ビルドを作成するのは非効率的なので、 Jenkinsを用いてサーバーでビルドを作成しています。 Pull RequestにbuildとコメントするとJenkinsにビルドパラメータを渡し、ビルド結果のURLを教えてくれるシステムが稼働しています。

f:id:kayac-mada:20161221221526p:plain