【Git中級者への第一歩】リリースプロセスの品質を上げるブランチ戦略、開発をもっと便利にするコマンドとは

Git中級者への第1歩第2回

2024/06/05 11:00

ポスト

　「Women Developers Summit 2023（デブサミウーマン2023）」で大反響だったセッション「Git中級者への第1歩」が、パワーアップしてCodeZineに帰ってきました。この連載では、コマンドの使い方やGitの効率的な学び方など、知っておくと役立つ情報をお届けし、基礎から更なるステップアップを目指すみなさまを応援していきます。第2回となる今回は、ブランチ戦略がテーマです。

ポスト

はじめに

　こんにちは、都内でソフトウェアエンジニアとして働いている藤澤です。﹁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も考えやすくなることも多いと思います。

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内