個人開発のためのGitブランチ戦略
皆様、個人開発でのブランチ戦略どうしてますか？
個人開発では、チーム開発のような厳格なルールが必ずしも必要ではありません。
しかし、負担にならない程度の運用ルールも必要です。
今回は私が実際に運用している個人開発アプリ限定のブランチ戦略について紹介します。
私のブランチ戦略：リリース用ブランチ集約タイプ
私は個人開発アプリを2週間に1度のペースで更新しています。（ちなみに第一と第三の土日）
なので、この更新サイクルに合わせたブランチ戦略を採用しています。
開発の全体の流れは以下のパターンで行っています。
- 現在のバージョンが1.2.1の場合、2週間後のリリースを見据えて
release_1.3.1_12のような形式（release_バージョン名_ビルド番号）でmainから新しいブランチを切ります。（例） username % git branch main * release_1.3.1_12 username % - 次回リリースに含める機能や修正はすべてこのリリースブランチに集約します。
- プレイストアに審査を出す前に、リリースブランチからmainにPRをマージします。
- mainに切り替えてビルドコマンド叩いて各プレイストアにリリースします。
- 「1」に戻って繰り返します。
この方法のメリットは、次回リリースの内容を一つのブランチにまとめることで、管理がシンプルになることです。
チーム開発では1イシュー1PRが基本ですが、流石にそこまでガチガチでやると色々負担もありますのでこの運用が今の所一番しっくりきてます。
ただし、コミットは細かく分けて、何を変更したのか後から見返しても分かるようにしています。（大事）
あと、副次的な効果として、リリースビルド前に pubspec.yaml（Flutter）のversionを更新しますが、現在のブランチと同じ番号にしたら良いのでちょっと楽です。笑
毎回、セマンティックバージョニング (X.Y.Z)の付け方に一瞬悩んでいるのでね、、
若干話がずれますが、2週に1度の更新なのでMAJORかMINORです。PATCHは最初だけ使ってました。
- **X (MAJOR)：
- **Y (MINOR)：
- **Z (PATCH)：
他の開発者のアプローチ
個人開発者がどのようなブランチ戦略を採用しているか調べてみると、様々なパターンがありました。
「mainだけ」派
勇者タイプと呼びましょう。
mainブランチだけで開発を進める強者です。
「devブランチ」派
健全タイプと呼びましょう。
一応devだけ切ってるよ！！毎回ブランチは切るのは手間だけど！
というタイプです。
「毎回ブランチ」派
尊敬タイプと呼びましょう。
機能ごとにブランチを切る真面目派です。
チーム開発の習慣をそのまま個人開発にも転用している方が多かったです。
結局何がいいのか
正直好みです。
ただ、定期的なリリースサイクルがあるなら、リリース単位でブランチを管理するのが合理的な気がします。
急ぎのバグ修正が必要な場合は、hotfixブランチを別途切ることもあります。
色々やってみて一番自分に負担が少なく運用しやすいやり方でいいと思います。
業務と個人開発は別なのでブランチ戦略も実装もやりやすいようにやったら良いです！
終わり
あなたはどのようなブランチ戦略を採用していますか？
もし他にも効率的な方法があれば、ぜひコメントでシェアしてください！
Discussion