ここでは Git を前提とし、ブランチ戦略を以下のように定義します。
<aside> 💡 効率的な Git ワークフローを構築するための ブランチの命名規則や作成・マージなどの運用ルール
</aside>
モバイルアプリ開発におけるブランチ戦略は Git flow が選択されることが多いかと思います。
しかし、開発する人数が増えるに従って Git flow では非効率になってしまいました。
例えば、リリースしてから不具合が発覚した場合 hotfix ブランチを運用する必要があります。
hotfix ブランチは develop ブランチへのバックマージが必要となりますが、その運用の手間を嫌って hotfix が発生しないように develop ブランチへのマージを2,3日控えるという運用になっていました。開発する人数が増えるに従って、その間に溜まる PR が増えてしまっていました。
また、開発する人数が増えるに従って、直近のリリースだけでなく、その次のバージョンの開発も同時並行に進むようになり、 develop ブランチだけでは管理しきれなくなりました。
develop-** ブランチを作成していますが、 develop ブランチへの追従やコンフリクト解消などが手間となっています。
上記の理由から、ブランチ戦略の見直し・検討・設計を行いました。
ブランチ戦略には Git flow, GitHub flow, GitLab flow などがありますが、どんなブランチ戦略を採用するかを検討するために観点を洗い出しました。
モバイルアプリではサポートするバージョンが１つしかありません。そのため、ブランチもリリースに対応するブランチがあればリリースされたバージョンの履歴がわかりやすくて良さそうです。
リリースバージョンに対応するブランチがあると、不具合調査で git bisect しやすそうです。