ソフトウェア開発のためのブランチ戦略

概要

ブランチ戦略は、複数の開発者が協力してコードを効率的に管理するための方法です。ブランチ戦略はさまざまな種類があり、それぞれの特徴に応じて適切なブランチ戦略を選択して使用する必要があります。今回のブログポストでは、ブランチ戦略の種類と使い方について紹介します。

git-flow戦略

git-flowブランチ戦略はVincent Driessenによって提案されたブランチ戦略です。ブランチ戦略の中で最も有名なブランチ戦略であり、多くの企業が使用しています。

https://nvie.com/posts/a-successful-git-branching-model/

git-flowブランチ戦略はmaster、develop、feature、release、hotfixブランチで構成されています。

master ブランチ
- master ブランチは常に製品としてリリースできる安定したコードを維持するために使います。
- リリース可能なバージョンはこのブランチでTagとして管理されます。
develop ブランチ
- develop ブランチは次のリリースのために開発するコードを含みます。
- 新しい機能とバグ修正を行うブランチはここで作成します。
feature ブランチ
- 新しい機能を開発するためのブランチで、developから作成します。
- 各機能は別々のブランチで開発し、開発が完了したらdevelopブランチにマージします。
release ブランチ
- リリースを準備する段階で使用するブランチで、developブランチから作ります。
- バージョン番号の更新、ドキュメントなどの準備作業を行い、テストを行った後、masterとdevelopブランチにマージします。
hotfix ブランチ
- 緊急のバグ修正を行うためのブランチです。masterブランチから作ります。
- 修正が完了したらmasterとdevelopブランチにマージします。

git-flowではreleaseブランチがmasterにマージされる時、hotfixブランチがmasterにマージされる時リリースされます。その後、Git tagを使ってリリースされた時点を管理します。

GitHub flow戦略

GitHub flowは簡単で直感的なGitブランチ戦略の一つでGitHubが提案しました。この戦略は主にWeb開発でリリース管理を行うための簡単なワークフローを提供します。

https://docs.github.com/get-started/using-github/github-flow

GitHub flowブランチ戦略はmaster、featureブランチで構成されています。

master ブランチ
- master ブランチは常に製品としてリリースできる安定したコードを維持するために使います。
feature ブランチ
- 新しい機能を開発するためのブランチで、masterから作ります。
- このブランチでコードを修正し、コミットします。
Pull Request(PR)
- 機能と作業が終わったら開発者はmasterブランチにマージするためにPull Requestを作成します。
- コードレビューやテストを通過しないとマージできません。
コードレビューとテスト
- 他の開発者がPull Requestをレビューします。
- 自動化されたテストが通過すると安全だと見なされます。
Merge
- Pull Requestがすべての条件を満たすとmasterにマージされます。

GitHub flowではfeatureブランチがmasterにマージされるとリリースされます。GitHub flowでは頻繁にリリースすることが重要であり、ユーザーに新しい機能とバグ修正を迅速に提供できます。

GitLab flow戦略

GitLab flowはGitLabが提案したブランチ戦略です。GitLab flowは基本的なGitHub flowと同じです。ただし、リリースのタイミングがある場合(iOSアプリのリリースにはアプリ審査があり、定期的にリリースするサービスなどがこれに該当します)に使用できる戦略です。

https://docs.gitlab.co.jp/ee/topics/gitlab_flow.html

GitLab flowブランチ戦略はmaster、featureブランチとリリースのためのブランチ(production, stagingなど)で構成されています。

master ブランチ
- master ブランチは常に製品としてリリースできる安定したコードを維持するために使います。
feature ブランチ
- 新しい機能を開発するためのブランチで、masterから作ります。
- このブランチでコードを修正し、コミットします。
Merge Request
- 機能と作業が終わったら開発者はmasterブランチにマージするためにMerge Requestを作成します。
- コードレビューやテストを通過しないとマージできません。
コードレビューとテスト
- 他の開発者がMerge Requestをレビューします。
- 自動化されたテストが通過すると安全だと見なされます。
production(stable, staging) ブランチ
- production(stable, staging) 環境にデプロイ可能な安定したコードを持つブランチです。
- デプロイするために作成するブランチで、masterブランチから作ります。
hotfix ブランチ
- 緊急のバグ修正を行うためのブランチです。masterブランチから作ります。
- 修正が完了したらmasterとproductionブランチにマージします。

GitLab flowではproductionブランチがmasterにマージされるとリリースされます。開発した内容（featureブランチ）はmasterにマージして、リリースのタイミングでmasterブランチからproduction(stable, staging)ブランチを作成してデプロイします。

Trunk-Based Development戦略

Trunk-Based Development(TBD)戦略は、迅速なソフトウェアリリースと高い協力を目指すシンプルで効果的なGitブランチ戦略です。TBD戦略は継続的インテグレーション(CI)と継続的デリバリー(CD)を強調します。

https://trunkbaseddevelopment.com/

TBDブランチ戦略は1つのブランチ(trunk, master, main)で構成されています。

Branch strategy - Trunk-Based Development

1つのブランチ(trunk, master, main)
- TBDでは主にmaster(main)ブランチのみを使います。masterブランチは常に製品としてリリースできる安定したコードを維持するために使用されます。
頻繁なコミット
- TBDでは開発者は小さな単位で頻繁にコミットします。これにより、コードの変更を素早く共有し、ブランチ間の競合を最小限に抑えます。
Pull Requestではなく直接コミットとコードレビュー
- 小さな変更に対してPull Requestを作成する代わりに、masterブランチに直接コミットしてコードレビューを行います。これにより、ブランチ間の競合を最小限に抑えることができます。
リリース
- masterブランチのみを管理するため、リリースはタイミングを決めて行います。

TBDでは全メンバーが24時間以内にコミットするようにします。つまり、24時間以内にコミットできるほど小さなコードを頻繁に書くことが重要です。

TBDはGoogleが使用することで有名です。

Scaled Trunk-Based Development戦略

Scaled Trunk-Based Development(STBD)戦略はTrunk-Based Development戦略と同じですが、masterブランチに直接コミットせず、featureブランチを作成してコミットし、featureブランチをmasterにマージします。

https://trunkbaseddevelopment.com/

STBDブランチ戦略はTBDと同じく1つのブランチ(trunk, master, main)とfeatureブランチで構成されています。

1つのブランチ(trunk, master, main)
- STBDでは主にmaster(main)ブランチのみを使います。masterブランチは常に製品としてリリースできる安定したコードを維持するために使用されます.
feature ブランチ
- 小さなコミットを行うためのブランチで短いライフサイクルを持つブランチです。
リリース
- masterだけを管理するため、リリースはタイミングを決めて行います。

TBDはmasterブランチに直接コミットし、コードレビューを行うために独自の開発体制が必要です。STBDはTBDの利点を活用しながら、このような独自の体制を構築するのが難しい場合に使用できるブランチ戦略です。