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

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

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

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

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

想像に難くないことですが、mainブランチだけでは以下のような問題が起こりえます。

• 複数人で開発したとき、履歴が競合してプッシュできない
• 複数の開発を並行するとき、履歴が混ざってしまう
• 開発中のソースコードとリリース済みのソースコードが区別できない

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

developブランチを使用することで、開発中のソースコードとリリース済みのソースコードを分けて管理できるようになります。mainブランチには本番環境にデプロイ済みのソースコードを、developブランチには開発中のソースコードを保管するようにします。

これにより、本番環境にデプロイする際、現在の状態とリリースする状態との差分が分かりやすくなることがメリットだと感じます。

しかし、これだけではまだ以下の問題が残ります。

• 複数人で開発したとき、履歴が競合してプッシュできない
• 複数の開発を並行するとき、履歴が混ざってしまう

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

開発したい機能や担当者ごとにfeatureブランチを作成することで、複数の機能開発を並行させることができます。コミット履歴も追いやすくなります。

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

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

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

開発を進める途中で本番環境にバグが見つかった場合、developブランチでバグを修正すると他の開発が完了するまでソースコードをデプロイできず、修正の反映が遅くなってしまいます。

そこで、mainブランチから直接ブランチを切ってバグ修正のみ行い、mainブランチにマージすることで、迅速に修正を反映する方法が考えられます。このブランチをhotfixブランチと呼んでいます。

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

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

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

リリース前にdevelopブランチからreleaseブランチを切ることで、他の開発と並行してリリースに向けたバグ修正やメタデータ設定を行うことができます。

リリースの準備が完了したら、mainブランチにマージします。

releaseブランチも、作業が完了したらdevelopブランチにマージし、バグ修正などを取り込みます。