ブランチ戦略の必要性とgit-flowのメリットを理解した

最近、Gitをチーム開発で使うようになり、なぜブランチ戦略が必要になるのか身をもって理解できるようになってきました。

そこで、本記事ではブランチ分けの必要性を理解するまでの道のりを、git-flowベースで紹介してみます。

git-flowがすべての開発で必要十分というわけではないと思いますので、本記事を参考に、各自の環境で必要と思われるブランチ分けを実践していただければと思います。

参考：A successful Git branching model

1. mainブランチしかない場合

main ブランチしかない場合、いろいろな問題が考えられますが、特に大きな問題は開発中のソースコードとリリース版のソースコードを区別しにくいことです。

2. developブランチを使用する

develop ブランチを作成し、develop ブランチで開発を進め、main ブランチには安定したリリース版のソースコードを置いておくようにします。

これにより、リリース版の変更履歴が分かりやすくなったり、main ブランチを起点に自動デプロイを組むことができたりするようになります。

しかし、これだけではまだ問題が残ります。例えば、複数の機能を並行して開発すると、いろいろな変更が混ざって開発しにくくなったり、後から履歴を追いかけにくくなったりするおそれがあります。

3. featureブランチを使用する

開発する機能ごとにブランチを作成することで、複数の機能を並行して開発しても、作業が進めやすくなり、コミット履歴も追いやすくなります。

featureブランチは名前が feature である必要はなく、機能開発や修正が必要になるたびに名前を付けていくつも作っていきます。特定の話題に関する開発が完了したら、featureブランチは develop ブランチにマージして削除します。

ここまででブランチ分けの基本形は完成したように見えますね。ここからは、さらに細かいニーズに応えるブランチを考えます。

4. hotfixブランチを使用する

※featureブランチは図から省略しています

開発を進める途中でリリース版にバグが見つかった場合、develop ブランチでバグを修正しようとすると、develop ブランチで開発しているすべての機能のリリース準備が完了するまで修正をリリースできなくなってしまいます。

そこで、main ブランチからバグ修正のみ行うブランチを切り出し、修正完了後に main ブランチにマージすることで、迅速に修正を反映することができます。このブランチをhotfixブランチと呼びます。

修正完了したhotfixブランチは develop ブランチにもマージすることで、開発中のソースコードを最新化して後戻りが発生しないようにします。

5. releaseブランチを使用する

※featureブランチは図から省略しています

リリースする機能が開発できたら develop ブランチからreleaseブランチを切ることで、他の開発と並行して今回のリリース準備（バグ修正やメタデータ設定など）を進めることができます。

リリース準備が完了したら、releaseブランチを main ブランチにマージしてリリースします。あわせて develop ブランチにもマージし、開発中のソースコードも最新化します。