Unity 3.5でバージョン管理をする

およそコンピュータを使った仕事に該当するものでしたら何でも、複数の人物が同時に作業するための何らかの仕組みが必要になるのは、コンピュータを使った仕事に関わっている人でしたら皆ご存知かと思います。特に開発業務といえばgitやhgといったバージョン管理システムの出番になります。そういうわけで今回は Unity プロジェクトでのバージョン管理について一ヶ月間ほどやってみた結果をご紹介したいと思います。


■Unity 3.4以前の場合

そんな暗黒時代のことは忘れましょう。


■Unity 3.5以降の場合

Unity 3.5から新しい仕組みが導入され、 Unity Asset Server というビルトインの ボッタクリ バージョン管理システムを使う以外に、好きなバージョン管理システムを使ってUnityのプロジェクトをバージョン管理することができるようになりました。これを使わない手はありません。まずは公式のガイドを見てみましょう。
http://unity3d.com/support/documentation/Manual/ExternalVersionControlSystemSupport.html

これによると、以下の手順を踏むのが良いようです。

1. メニューの Edit -> Project Settings -> Editor から、 Version Control の Mode という項目を探し、 Metafiles を選択する。これで外部のバージョン管理システムが導入できるようになります。このチェックを入れると、
   • Libraryディレクトリが重要なメタデータを管理するディレクトリではなくただのキャッシュディレクトリになり、バージョン管理をしなくてよくなる。
   • 新たにAssetsディレクトリ以下のすべてのファイルとディレクトリについて.metaファイルが生成される。
   • 新たにProjectSettingsディレクトリが生成される。
2. メニューの Edit -> Project Settings -> Editor から、 Asset Serialization の Mode という項目を探し、 Force Text を選択する。この手順はどちらかと言うとおまけです。これを実行すると、ほとんどのAssetファイルがバイナリではなくテキスト形式で保存されるようになり、diffやmergeが行えるだけではなく差分だけをコミットするようになるためバージョン管理システムが扱うデータ量が減ります。
3. プロジェクト配下のAssetsディレクトリとProjectSettingsディレクトリをバージョン管理システム配下に追加する。それ以外のファイルは追加しなくて良い。

たったのこれだけです。なかなか簡単そうですね！ということで早速やってみました。

・・・ところがぎっちょん、実際にやってみると出るわ出るわ問題の山。


■.metaファイルがどこからともなく勝手に生成される

これが最大の問題です。外部バージョン管理をするためにUnityが.metaという名前のメタファイルをテキスト形式で生成するのですが、コイツがトラブルを起こしまくります。

• ファイル削除時に.metaを消すのを忘れて、同じ名前のファイルをあとから作成しようとして.metaがぶつかりトラブルになる
• ファイルも.metaもバージョン管理下から確かに消したはずなのに、なぜか.metaファイルだけが勝手に復活している
• ブランチを移動すると急に.metaファイルが湧いてきて、ブランチのマージ時に衝突する

主要な原因はUnityが空のディレクトリから.metaファイルを生成しているためです。 以下のようなケースで、中身が空のディレクトリというのは容易に生成されてしまいます。

gitの場合

gitはディレクトリをバージョン管理対象に含めないため厄介なことになります。通常はgit pull時にmerge/rebaseが実行され、その際に空になったディレクトリは削除されるのですが、merge/rebaseの最中に衝突が発生したりすると問題が大きくなります。merge中に裏でUnityが動いていると空ディレクトリの.metaがその場で生成されて、考えるだけでも恐ろしいことになったりします。

通常はこれで問題ないのですが、merge/rebase時に衝突が発生していて、裏でUnityが動いていたりすると酷いことになるみたいです。

hgの場合

hgはgitと同様にディレクトリがバージョン管理対象外なのですが、hg update時に空になったディレクトリをきちんと削除してくれます。これはupdateがworking directoryの中身を指定されたリビジョンの状態にするから、という認識です。gitと違いpullやupdate時にmerge/rebaseを実行しないためトラブルになりづらいのか？などと考えてますが実際に苦労したわけではないのでよくわかりません。おそらくgitよりはトラブルになりづらいとは思います。

1および3にupdateすると、きちんとFolderやOtherFolderが削除されてくれます。いい感じ。

svnの場合

ディレクトリもバージョン管理の対象にするので問題ありません。以下の図を参照。

r2のような削除の仕方をするとFolderが残ってしまうためFolder.metaが生成されてしまうのですが、普通はディレクトリを消したときはr4のような削除の仕方になるので問題がないはずです。

また中身が事実上空なディレクトリ（すでに使われていない.metaしか入っていないディレクトリなど）が亡霊みたいにさまよっていて延々と自身の.metaを書き出し続けたり、善意で予め作っておいた空ディレクトリが.metaを吐き出していることを知らずコミットされては削除されを繰り返していたり、二人が同時にディレクトリを削除しようとして片方のコミットが衝突して結果が壊れてしまったりなど、枚挙に暇がありません。

元ファイルを移動したり削除した際に.metaを消さなくてはいけないというだけでも極めて面倒で、相当なトラブルになりました。そもそもがUnityを使っているプロジェクトのメンバーが全員バージョン管理システムに慣れていないため、とりあえずバージョン管理システムのGUIツールがいうがままに変更を全部コミットするだけという具合の運用に。.metaだけが延々と残って衝突が繰り返されるという悲惨な状況が発生してしまうこととなりました。これはUnityのせいではなくメンバーがバージョン管理の考え方を正しく理解していないのが問題なのでツールは何を使っても発生しうるのですが、.metaがなければここまで問題は拡大しなかったと思います。

いっそignoreしてしまいたいぐらいなのですが、この.metaにファイルごとのメタ情報が全て詰まっているため、当然ignoreするとプロジェクトがブッ壊れます。これはひどい＞＜

本家のドキュメントで例にされているのがgitでもなくhgでもなくsvnであるあたりを見ると、なんだかsvnで動作させることしか考えてなさそうな印象です・・・


■.unityファイルがマージできない

.unityファイル自体はテキスト形式にできるのですが、中で使われているAssetのIDがちょっと触れただけでものすごい勢いで変化したり、他人の環境では別の値になったりするため、殆どの場合マージできません。iOSプロジェクトのxcodeprojファイルみたいな感じです。こればかりはマージを諦めるしかありません。


■まとめ

最初はgitを使って管理をしていたのですが、上記に挙げたような問題が多発しまくって回らなくなってしまいました。別のバージョン管理システムを使うことも検討したのですが、そもそもメンバーのバージョン管理に対する知識が足りていない上に.metaが存在する以上hgやsvnに変えても問題が根本的に解決しそうにないと判断し、結局社長に頼んでAsset Serverを購入して試してみることになりました。がっかしです＞＜ ですがAsset Serverならば.metaを使わないでバージョン管理できるので問題を根本的に解決できそうです。

逆に言えば.metaに気をつければそれ以外の箇所ではgitでもあまり問題になりませんでした。バイナリを大量に扱うため重いのではないかと懸念されていましたが、github経由ででも問題なくpush/pull出来る程度の重さにしかならなかったです。ということで.metaとうまく付き合えるチームメンバーが揃っているのであれば、Asset Serverなしでも十分やっていけるのではないかと思いました。

個人的にUnityでバージョン管理をする際におすすめする外部バージョン管理システムはsvn、可能であればPerforceです。git/hgのようにブランチを主体とするバージョン管理システムはブランチを切り替えた瞬間に.metaに殺されるケースが多々あるため、ブランチの使用そのものが非推奨となり、力が発揮できません。mergeについてもバイナリファイルやmergeできないテキスト形式のファイルが多くて結局意味がない気がします。どうしても分散VCSを使いたい！というならhgをお勧めします。ブランチ切り替えは常にupdate -Cすることで対応できるかなと。bazaarはわからないのでノーコメント。gitはpull時の衝突の最中に裏でUnityが動いていて大爆発するケースがあったのでやめておいたほうが良いです。hgなら少なくともpull/update時に爆発することはないはずですからね。

次はAsset Serverを試してみて、使用感を書いてみようかと思います。果たしてお値段に見合った効果は得られるのか！？乞うご期待です！

github で pull request をされたとき・するときの手順

github に自分のリポジトリを公開していると、たまに pull request をされることがあります。また逆に、他人のリポジトリのコードを使っていて、どうしても気になるバグを見つけて修正したときなど、相手に pull request を送りたいことがあります。こんなときにどうすればよいかをまとめてみました。


■pull request をしたいとき

pull request をしたいときは、まず相手のリポジトリを fork する必要があります。


このボタンをぽちっとな。

fork したら、 fork して自分の管理下に入ったリポジトリを clone して、コードを修正します。

git clone https://akisute@github.com/akisute/asi-http-request.git

コードの修正が終わったら、自分の fork したリポジトリに push しておきます。

git push origin master

ではコードの修正が終わったので pull request をします。


このボタンをぽちっとな。


するとこうなります。デフォルトでは相手の master に対して自分の master を pull request することになりますが、もちろんこの画面で変更可能です。 request をする先のリポジトリ・ブランチと、リクエストされるブランチをそれぞれ指定できます。それからコメントをつけて送れます。ここでつけたコメントは相手側のリポジトリの Pull Requests タブに記載されるので、それなりにかっこいい内容を書いておくと良いかと思います。あとは相手が受け入れてくれるのを待つばかりです。自分のコメントにコメントがついたらメールとかで通知が来ますんで、適当に返事して相手と連絡を取りながらやる感じになります。


■pull request をされたとき

逆に自分が pull request をされることもありますので、そのときの対処法も。


pull request されると、こんな風に Inbox の Notifications の中に通知が来ます。


対象のリポジトリの Pull Requests タブにもこんな具合でリクエストが入ります。


クリックしてリクエストの詳細を開きます。ファイルの diff 一覧とかどっからどこに対してリクエストが飛んでいるのよとか全部ここで見られます。相手のコメントに対してコメントを返したり、 diff に対してコメントをつけたりできます。 diff につけたコメントは相手にも公表されます。

ここで相手とコメントやりとりとかして、じゃあ取り込もうか、となりましたら、実際に pull request を取り込む作業を行います。自分のリポジトリにマージ用のブランチを用意して、 pull して確認し、問題なければマージ用のブランチと本線をマージして終了。コマンドがよくわからなくても github が全てのコマンドを表示してくれるのでそれを見れば一発です。本当に親切。以下、 master ブランチに対して pull request があったとすると、

git checkout -b pull-request-master master
git pull http://github.com/applicant/his-repository
# 相手のコミットが自分のブランチに pull されてくるので、この状態で動作を確認する
# merge 作業が発生するならここで行う
# 問題がなさそうなら
git commit
git merge master
git push origin master

push まで完了したら先ほどの pull request のページから取り込み完了したよボタンを押しておきましょう。


■おまけ: 自分が fork しているコードの fork 元リポジトリが更新されたので、こちらも最新にしたい

実はこれは pull request をされたときとあんまり変わりません。対象の相手のブランチを自分の fork しているコードに pull すればよいのです。

git checkout -b merge-master master
git pull http://github.com/parent/parent-repository
# 相手のコミットが自分のブランチに pull されてくるので、この状態で動作を確認する
# merge 作業が発生するならここで行う
# 問題がなさそうなら
git commit
git merge master
git push origin master

Mercurial と git の branch にまつわるちょっとした tips 3選

3選とか言ってますが大した内容ではございません＞＜ すみませんすみません＞＜


■１：gitのbranchは跡形もなく消せる
ほとんど常識ですが、以下のコマンドでgitのbranchは消せます。

git branch -D

このコマンドを実行すれば、たとえHEADに対してマージされていなくてもそのままブランチを消すことができます。ということで、ちょっとしたテストコードなどはブランチを切ってそこで実験し、後からブランチごとたたき落とす運用が可能です。

余談ですが、gitのbranchはSubversionと使い勝手や実装が似ている感じがします。Subversionのbranchもタダのディレクトリコピーなので、好き勝手に作って消してが可能ですから。


■２：Mercurialのbranchは基本消せない、「未使用」か「クローズ」にはできる
問題はここから。Mercurialのbranchは、基本的に完全に跡形もなく削除することができません。また、マージしていないブランチがあるとpushの際に怒られます。そのため、ちょっとしたテストコードをブランチ切ってそこで作成し、いざいらなくなったので削除しようと思うとえらい大変なことになります。

一応、ブランチを「クローズ」するコマンドを使うことで常用範囲内からは消す事が可能ですが、完全に情報が消えたわけではないのでリポジトリのサイズは小さくなりません。ゴミが溜まります。もしMercurialでテストコードを管理しようと思うならば、branchを切るのではなくリポジトリごとcloneしてそちらでテストする運用にすればよいです。


■３：Mercurialのbranchに数字で名前を付けてはならない
gitと違ってMercurialのリビジョンには、簡便のため、リビジョンのハッシュIDの他にリビジョン番号が1番から採番されるようになっています。で、各種操作の際に、このリビジョン番号を代わりに指定して実行することが可能です。

ここまではOK。

問題はbranchに数字の名前が付けられることで、もしbranchに数字の名前を付けてしまった場合、Mercurialはその数字をリビジョン番号として解釈してしまい、ブランチ名指定の処理ができなくなってしまいます。

hg branch 255
hg commit -m "created branch 255 for ticket #255"
hg update 255
# ブランチ255ではなくリビジョン番号255番に対してアップデートしようとする・・・

ただそれだけなのですが、チケットシステムなどと連携しているとよくチケット名でブランチを切る事があると思いますので、そのような際にはticket255などという風に指定するほうがよいかと思います。

jweeklyforecast (server) のリポジトリを公開しました

http://github.com/akisute/jweeklyforecast/tree/master

先日話題にいたしました、天気予報用API提供用サーバーjWeeklyForecastのリポジトリを作成いたしましたので、取り急ぎご報告だけさせていただきます。


ちなみに中身はスッカスカです。まだGoogle App Engineの本番サーバーにもアップできていない状況なので、何とか今週末までにはアップしたいです！

CS193P Cocoa Programming - ソースコードをgithubに公開いたしました

gitの練習もかねてここまでの成果ソースコードを公開してみました。
http://github.com/akisute/akisute_cs193p/tree/master

特に見所はありませんが、一応自分の勉強用として。

githubに自分のリポジトリを作ってコミットしてみる

• gitとは分散リポジトリ、分散リポジトリについてはこちらのページを参照
• 要するにローカル上のリポジトリ＋github上のマスターリポジトリを用意してくれる感じらしい
• 手元のリポジトリにコミットするのがcommit、リモート（他人の）リポジトリにコミットするのがpush
• githubへのpushには公開鍵を利用したSSHによる認証が必要
• 自分のマシンで公開鍵と秘密鍵を作成し、公開鍵をgithubに追加。秘密鍵をssh-agentとやらを使ってローカルマシンにインストールする

私の周りのTwitter界隈でgithubなる良く分からないシロモノが大流行しているので、私も便乗してみることにしました。
バージョン管理システムの経験はCVSとSubversionのみ、しかも両方ともEclipseから使ったことがあるだけでコマンド操作なんて全く分からないど素人ですが、なに、使ってみれば分かるさ！

まずはgitをMacBook Airにインストール。MacPortを使えば一発です。

sudo port install git-core

これだけなのですが、依存関係がひっじょーーーに多いのでインストールに1時間ぐらい待たされました。

次、githubに自分のアカウントを作ります。これは説明不要。

次、githubに自分用の楽しい楽しいリポジトリを作ります。これも説明不要。分かりやすいです。


できました。名前はakisute_cs193p。そのまんま。

次、画面に表示された念仏を、そのまま何も考えずに実行します。

git config --global user.name "akisute"
git config --global user.email "this_is_my_boomstick@gmail.com"
cd ~/Documents/Xcode/
mkdir akisute_cs193p
cd akisute_cs193p
git init
touch README
git add README
git commit -m 'first commit'
git push origin master

と、最後のコマンドを入力したところでなにやら訳の分からないエラーが出て停止。困りました。
とりあえず何をやっているのかを少しずつ把握していくことにします。

まず最初の2行でコンフィグ。名前とメアドを決めてね、ということらしいので、適当に入力。
次、自分のXcodeプロジェクトがある場所に移動して、リポジトリ用のディレクトリを作って、
git initコマンドを実行してその場にリポジトリを作りました。その場に、と言うのがポイント。
これでgithub上とローカル上に2個の同じリポジトリが完成したことになります。
touchコマンドでREADMEファイルを作成。
READMEファイルがあると、github上でREADMEファイルの中身が表示されるみたいです。
Licenseとか表示するのに便利そうですね。
次のgit add READMEで作ったファイルをgit様の管理下におきました。
git addはファイルを管理下に置くときだけではなくて、コミットの前にも実行する必要がある？みたいです。
git add .（ピリオドを忘れずに）とするとカレントディレクトリ以下の全ての存在をgit様の管理下に置くのだハハハハーらしいです。便利ですね。
変更追加を管理下においたら、git commit -m 'first commit'でコミット。
どうやら-mは引数でコメントを入力するオプションみたいです。
-mオプションを指定しなければ、自動的にvimが立ち上がってコメントを求められます。
コメントなしのコミットは出来ません。

最後、問題のgit push origin master。一体全体何をしているのか分からなかったので、まず調査してみました。
http://github.com/guides/git-cheat-sheet
ここでgit pushの例を見てみると、リモートリポジトリoriginに対して、ブランチ名masterをコミットしているらしいです。
要するにここでは、github上に一番最初に用意したリポジトリに対して、既存のブランチmasterをコミットするということかな。
どうして自動的にgithubに対してpushしてくれるのかはわかりませんが、きっと最初の設定がそうなっているんでしょう。

では分かったところで、よく分からない理由でgit push出来ない問題を解決しましょう。まずは適当に検索・・・
git/github - TOBY SOFT wiki
ヽ( ・∀・)ノくまくまー(2008-06-02)
すると偉大な先人たちが既に答えを導いておられました。素晴らしい！
要するに、git pushの際にSSHの認証をしたいんだけど、
秘密鍵と公開鍵がないから認証できないよ、ということらしいです。

まずは鍵を作ります。以下、@ITからコピペ＆一部改変。
＠IT：sshでパスワードなしにログインするには

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/akisute/.ssh/id_rsa):　←［Enter］キー
Enter passphrase (empty for no passphrase):　←パスワードを入力
Enter same passphrase again:　←同じパスワードを入力
Your identification has been saved in /Users/akisute/.ssh/id_rsa.
Your public key has been saved in /Users/akisute/.ssh/id_rsa.pub.

できました。
次、githubに戻って、accountページから公開鍵を登録します。

less ~/.ssh/id_rsa.pub

この結果を何も考えずコピーして以下の画面に貼り付ける。


できました。改行とか入っていないかだけは注意。改行したらダメらしいです。

@ITの例では、やれchmodしろだの鍵を作ったらどうのこうのしろだのとか書いてますが、無視。
要するにサーバー側に公開鍵を置いて、クライアント側に秘密鍵を置いておけばいいようです。
今回はgithubがサーバー様なので、githubに公開鍵を渡せばいいってことですね。

次。以下のコピペ呪文を詠唱します。何も考えずに力を抜いて楽にして。

eval `ssh-agent`
Agent pid 12345
ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/.ssh/id_rsa:　←パスワードを入力
Bad passphrase, try again for /home/.ssh/id_rsa:　←同じパスワードを入力
Identity added: /home/.ssh/id_rsa (/home/.ssh/id_rsa)

できた。凡人凡妖怪の私には何が起こったのかすらわかりません。
注意点はただひとつ、`ssh-agent`の`は'じゃなくて`です。Shift+@。

このコマンド入力によってgithubへの認証が可能になる！らしいです。早速試してみます。

git push origin master

おお！今度は成功！
調子に乗っていろいろ追加してみます。

git add Presense
git commit -m 'first commit'
git push origin master

これで俺もgitマスターだぜ！と調子に乗っていたら、


出ました、Mac OS Xの恥部（と勝手に自分が思っている）、.DS_Storeです。
これはリポジトリに含めたくないですね。どうすればいいんでしょう？
答えは簡単、.gitignoreというファイルを作って、お守り代わりにリポジトリのルートに配置すればいいらしいです。

build
.DS_Store
*.o
*.ob
*.pbxuser
*.tmproj
*.model*
*.mode*
*.build

このお守りを置けば、git add時にここに書いてあるパターンにマッチするファイルはaddされないらしいのですが、
すでにaddされてしまったものについては自分で消すしかありません。

git rm .DS_Store
git commit -m 'removed DS_Store'
git push origin master

まぁ、ざっとこんなもんよ、なんてね。

CVSやSubversionと比べると、ソースコードを公開するのが非常に楽でいい感じです。
ネットワーク環境が無くてもローカルのリポジトリに対してコミットできると言うのも地味に嬉しいところ。
過去の変更履歴を見たりブランチを切ったりするコマンドについては、おいおい学んでいこうと思います。