はじめに

ゲーム開発に合ったgit運用を模索する機会があり、その時のメモです。
主にスマートフォンゲーム開発をターゲットにしています。

リポジトリ分割

リポジトリを作成する際、リリースするタイミングによって分割します。
例えば、Unityの開発でResourcesフォルダ以下をAssetBundle化する場合
Resourcesフォルダをリソースリポジトリに分けて運用を行います。

これは後述するブランチ戦略との相性をよくするためです。

有名なブランチ戦略
git-flow
github-flow
gitLab-flow
gitworkflows

様々なブランチ戦略がありますが、以下の点からgit-flowをベースにすることにしました。
1. スマートフォンゲーム開発ではリリース作業が明確に存在する点
2. ツールが存在する点(SourceTreeにも内臓)
3. 複数バージョンリリースする点

ただ、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よりも複雑になっていますが、慣れてしまえは問題ありません。
特に複雑な部分はリリース時の作業のため、この辺りは自動化してしまったほうがいいかもしれません。