はじめに
ゲーム開発に合ったgit運用を模索する機会があり、その時のメモです。
主にスマートフォンゲーム開発をターゲットにしています。
リポジトリ分割
リポジトリを作成する際、リリースするタイミングによって分割します。
例えば、Unityの開発でResourcesフォルダ以下をAssetBundle化する場合
Resourcesフォルダをリソースリポジトリに分けて運用を行います。
これは後述するブランチ戦略との相性をよくするためです。
ブランチ戦略
有名なブランチ戦略
git-flow
github-flow
gitLab-flow
gitworkflows
様々なブランチ戦略がありますが、以下の点からgit-flowをベースにすることにしました。
- スマートフォンゲーム開発ではリリース作業が明確に存在する点
- ツールが存在する点(SourceTreeにも内臓)
- 複数バージョンリリースする点
ただ、gitworkflowsに関してはログを綺麗に保つブランチ戦略のため、併用も可能です。
素のgit-flowではdevelopブランチが一本しかありませんが、
ゲーム開発では複数のバージョンを同時に開発することがあるため、developブランチを複数運用します。
e.g. develop/develop
e.g. develop/1.0.1
※初期化の際に開発ブランチをdevelop/developとして作成します。
※develop/developには次のリリースに必要なものしかマージしてはいけません。
開発フロー
初回リリースまでをプロトタイプ期
初回リリース後を運用期とします。
git-flowに関しては、たくさん記事が上がっているのでそちらを参照してください。
プロトタイプ期
この時期は仕様変更も多く、柔軟な開発を行いたいため
develop/developブランチとFutureブランチのみを利用して、作業を行います。
運用期
複数バージョンの開発が必要な場合
複数バージョン開発が始まったときはバージョン名で開発ブランチを作成します。
e.g. develop/1.0.2
develop/developブランチには次のリリースに必要なものだけをマージし、
次々以降の機能はバージョンに合ったブランチにマージしていきます。
時折develop/developブランチをdevelop/1.0.2ブランチにマージして整合性を保ちます。
その後、develop/developのリリースが完了したら、develop/1.0.2ブランチをdevelop/developにマージして削除します。
旧バージョンを保守する場合
タグからsupportブランチを作成します。
1.0.1 リリース時に1.0.0も保守する場合
e.g. tag/1.0.0 → support/1.0.0 作成
supportブランチ作成後はコミットを行ずに、管理のためだけに使用します。
強制アップデートにより、保守が終わったものは削除します。
互換性リストの作成
ゲームは、クライアント、サーバー、リソースなどいくつものシステムが絡み合っているため、
どれか一つをバージョンアップすると正常に動かなくなる可能性があります。
そのため、正常に動くバージョンの組み合わせを記録しておくと何かと便利です。
クライアント、サーバー、リソース等どれか一つでもアップデートを行った場合、
関連リポジトリの最新タグおよびsupportブランチから互換性リストを作成します。
この作業はjenkins等で自動化するといいでしょう。
互換性リストがあることで、確実に動くバージョンの組み合わせにロールバックできるほか、
海外対応などで旧バージョンから追っかける開発をする場合非常に楽になります。
まとめ
リリースタイミングでリポジトリを分割
git-flowベースでdevelopを複数運用
管理用にsupportブランチを作成
互換性リストの作成
git-flowよりも複雑になっていますが、慣れてしまえは問題ありません。
特に複雑な部分はリリース時の作業のため、この辺りは自動化してしまったほうがいいかもしれません。