Gitフロー

Before: ブランチ運用ルールがなく、全員がmainに直接プッシュ。月1回のリリース前に「どのコミットまでがリリース対象か」が分からず、リリース延期が年4回発生。未完成の機能がストアに出てしまい、1つ星レビューが急増。

Gitflow導入: developを統合ブランチとし、featureブランチでの開発を必須化。リリース2週間前にreleaseブランチを作成し、バグ修正のみ許可。

After: リリース対象が明確になり、リリース延期が年4回→0回に。未完成機能の混入事故もゼロ。releaseブランチで安定化に専念できるため、リリース後の緊急パッチが月2回→月0.3回に激減。

状況: v2.0のrelease準備中（releaseブランチ存在）に、本番v1.9で決済処理のクラッシュバグが発覚。同時にv2.1向けのfeatureも3本開発中。

hotfixフロー: mainからhotfix/payment-crashを作成→原因特定→修正→テスト→mainにマージしてv1.9.1をリリース→developにもマージ。所要時間30分。

効果: releaseブランチの作業は中断不要。3本のfeature開発にも影響なし。以前はhotfixの手順がなく、mainへの直接コミットでさらなるバグを生んでいた（年3回の二次障害）。Gitflow導入後は二次障害ゼロ。

Before: developから直接mainにマージしてリリースしていたため、QAチームのテスト期間が確保できず、リリース後のバグ報告が月平均12件。

release運用導入: リリース1週間前にdevelopからreleaseブランチを作成。QAチームがreleaseブランチでテスト→バグ修正→再テストのサイクルを回す。その間developでは次の開発を継続。

After: リリース前に平均8件のバグを事前に検出・修正。リリース後のバグ報告が月12件→月2件に減少。品質ゲートの通過率が60%→95%に向上。QAチームの残業時間も月30時間→月8時間に削減。