はじめに
こんにちは、都内でソフトウェアエンジニアとして働いている藤澤です。「Git中級者への第1歩」の連載の2回目となります。第1回はコミットに着目した内容でした。第2回の今回は、ブランチ戦略に着目します。
対象読者
-
Gitコマンドの
add
、commit
、push
、pull
などは問題なく使える方 - Gitをより便利に使いたい、もう一段レベルアップしたいと思っている方
- Gitの学び方について知りたい方
リリースプロセスの品質を向上させる「ブランチ戦略」とは?
複数人で分担して開発を行う際、各自が自由にブランチを作成したりマージしたりしたら、どのようなことが起こるでしょうか。おそらく、最終的にどのブランチをリリースすれば良いのか、そもそもリリース対象の機能が集まっているブランチはあるのか、わからなくなってしまうと思います。
このようなことが起こらないように、ブランチの運用に関するルールや方針を決めるのが、ブランチ戦略です。どこからブランチを作成し、作業が終わったらどのブランチにマージをするのか、さらにマージの手順はどうするのか、といったルールを決めることで、複数人での開発をスムーズに進めることができます。
また、ブランチ戦略は開発フローを安全に進めることにもつながります。たとえば、皆さんのチームでも、以下のようなルールやCI/CDが導入されているのではないでしょうか。
- developブランチにマージされたら、GitHub Actionsで自動テストが実行される。さらに自動テストが通ったら、develop環境にデプロイされる。
- 本番環境で障害が起きた時には、mainブランチからhotfixプレフィックスをつけたブランチを切って障害対応をする。
上記のようにブランチ戦略を明確にすることで、CI/CDの構築も容易になります。もし毎回違うブランチからデプロイされるとしたら、自動化は難しいでしょう。そもそも意図しないコードをデプロイしてしまう可能性もありとても危険です。加えて、自動テストの実行についても、どんな時でもできるわけではありません。通常、プロダクトが成長するにつれて、テストの実行時間は長くなりますし、費用も掛かります。
実際の開発現場では、「開発用」「テスト用」「本番用」というように、複数のデプロイ環境を持つことも多いと思います。このような場合、各環境に対応するブランチが設定されることが一般的です。たとえば、「developブランチにあるコードはdevelop環境にデプロイされる」など、環境とブランチが対応付けられます(この時、必ずしも名前が一致している必要はありません)。
加えて、本番環境で障害が起こった場合、なるべく早くリリースして障害を解消したいと考えるはずです。そのためには、障害が発生している箇所に絞って対応を行うのが良いでしょう。このような状況では、本番環境にデプロイされているコードを起点に修正を行い、最小限の変更を行ってリリースするのが理想的です。「mainブランチに本番環境のコードがある」と決まっていると、スムーズに対応できます。また、本番障害に備えて、事前にブランチ操作の手順を検討することも可能になります。
リリース基軸で選択するブランチ戦略のメリットとは?──「git-flow」と「GitHub Flow」
今回は一般的によく知られているブランチ戦略を2つ、簡単にですが紹介します。
-
git-flow
開発ブランチを中心に置きつつ、「開発時には開発ブランチからフィーチャーブランチを作成」「リリース時にはリリースブランチを作成」というように複数のブランチを活用する戦略。
-
GitHub Flow
メインブランチを常にリリース可能な状態に保つ戦略。メインブランチからフィーチャーブランチを作成して開発を行い、完了したらメインブランチにマージする。
「git-flow」は、多数のブランチを用いる戦略です。開発中のコードとリリース対象のコードを明確に切り分けることで、開発を継続しつつ、リリースに関する作業をより安全に行えます。一方で、頻繁にリリースを行いたい、という場合には手間が増える傾向があり、リリース頻度が少ないプロダクト向きと言えそうです。
一方、「GitHub Flow」はシンプルなブランチ戦略です。理解しやすいと思いますが、メインブランチを常にリリース可能な状態に保つのは容易ではありません。メインブランチが常にリリース可能な状態になっているため、理論的にはいつでもリリースできます。頻繁にリリースを行いたいプロダクト向きと言えそうです。
上記で説明したように、ブランチ戦略にはそれぞれ向いているプロダクトと、そうではないプロダクトがあります。色々な考え方がありますが、プロダクトをどのようにデリバリーしていきたいのか、リリース頻度やタイミングを考えてみることで、開発フローやブランチ戦略、CI/CDも考えやすくなることも多いと思います。