ブランチ戦略

チームの中で何度も話したりする内容をなんとか整理したいです。

ブランチ戦略
- ブランチ戦略とは何か
- ブランチ戦略の種類
ぼくのコンテキスト
まとめ
参考文献

この辺りの話には色々宗教論争があったり、いやいやこのブランチ戦略の方がこういう点で良い、という話も分かります。また、そんなデメリットはこういうプラクティスで解決できる、という主張もある流でしょう。 Gitを使う開発対象はさまざまで、Webアプリケーションからデスクトップアプリケーションまで多岐に渡ります。要求レベルも様々、開発者のレベルも様々、私とあなたも異なる人間です。仲良くしましょう。

なお、僕たちが主に使っているのはGitLab Flowなので、その辺りの理由も説明します。

ブランチ戦略とは何か

ブランチ戦略は、ソフトウェア開発においてソースコードを管理するための方針や手法を指します。具体的には、各開発者や開発チームがどのようにソースコードの変更を管理し、それを統合するかに関する戦略を意味し、ブランチ戦略は以下のような要素に影響を及ぼします。

変更の組織化:
- ブランチ戦略を使用すると、開発者は新機能やバグ修正を個別のブランチで作業でき、それぞれの変更を主要なコードベースから独立して管理できます。これにより、コードの変更を整理しやすくなります。
リスクの軽減:
- 適切なブランチ戦略を使用すると、変更を本番環境に直接適用するリスクを軽減できます。開発者はブランチで変更をテストし、問題がないことを確認した後で本番コードにマージします。
チームの効率向上:
- ブランチ戦略は、複数の開発者やチームが同時に作業を進めることを容易にします。ブランチごとに作業を分割することで、作業が他の人の作業に影響を与えることなく、複数のタスクを同時に進めることができます。
コードの品質向上:
- ブランチを使用すると、各変更を個別にレビューし、テストすることが容易になります。これにより、全体的なコードの品質を高めることができます。

ブランチ戦略の種類

多く使われているブランチ戦略としては、以下の4つがあります。

ブランチ戦略	概要	デメリット	参考URL
Git-Flow	よく構造化されており、一定の規則に従っている。開発、リリース、ホットフィックス、メンテナンス用に様々な種類のブランチが存在する。	複雑さが増し、新たなメンバーが理解するまでに時間がかかる可能性がある。短期間でリリースする必要がある場合、過度に制約される可能性がある。	A successful Git branching model
GitHub Flow	非常にシンプルで、フィーチャーブランチを作成し、変更を行い、Pull Requestでレビューを受けてからマージする。リリースは定期的または必要に応じて行われる。	複雑な開発環境や長期間のプロジェクトに対応するのが難しい。また、継続的なデリバリー環境が必要となる。	GitHub Flow
GitLab Flow	GitHub Flowをベースに、さらに環境ブランチ（プロダクション、ステージング等）を追加し、リリース管理をより柔軟にした形。	複数の環境を管理する必要があるため、設定や管理が複雑になる可能性がある。	What is GitLab Flow?
Trunk-based Development	全ての開発者が単一のブランチ（トランク）から作業を開始し、頻繁にそのブランチにマージする。フィーチャートグルを使用して未完成の機能を隠すことが一般的。	頻繁なコミットとマージが求められ、コンフリクトが発生しやすい。また、大規模な開発チームや複雑なプロジェクトには適していない可能性がある。	Trunk Based Development

ぼくのコンテキスト

主とする開発対象はWebアプリケーションです。
チームは大体2〜10名程度で構成しています。
本番環境だけでなく、（開発チームが自由に触れる）開発環境や、ステージング環境といった複数の環境面が存在する

なぜ複数の環境面が存在するのか

複数の環境面の存在は、ブランチ戦略の適用可能性に大きな制約を与えます。

複数の環境面を必要とする大きな理由の1つは、ユーザに影響を与えない環境で品質を保証する必要があることでしょう。テスト中のコードは、機能面・非機能面の双方で稼働中の本番環境に影響を与える可能性があるため、本番環境とは別の環境で問題の有無を確認するケースが多いでしょう。また、その際のトラブルシュートに必要な情報を得ることを考えた時、本番環境ではない場合の方が容易です¹。

そして、上記のようなリスクがあり、そのリスクを許容可能なレベルまで小さくするような対案がない限り、いきなりの本番デプロイを許容しない組織も多いでしょう。結果として、複数の環境面を必要とする開発が多くなり、その複数の環境面があるという事実が、ブランチ戦略の選択肢を制限します。

複数の環境面を前提とした時のブランチ戦略

個々のブランチ戦略について、その適用可能性を探ると以下のようになるでしょうか。

ブランチ戦略	適用可能性	理由
Git-Flow	適用可能	Git-Flowは、異なるリリースブランチを使って開発、ステージング、プロダクションなどの異なる環境での作業を明確に分割できるため。
GitHub Flow	適用可能（ただし限定的）	GitHub Flowでは、プロダクションブランチ（通常はmain）に直接マージします。ステージング環境等は特定のブランチにデプロイすることで模倣することが可能ではありますが、明示的な環境ごとのブランチが存在しないため、一部の複雑なシナリオでは制限があります。
GitLab Flow	適用可能	GitLab FlowはGitHub Flowを拡張して環境ブランチを導入しており、それぞれの環境（開発、ステージング、プロダクション等）に対応するブランチが存在します。
Trunk-based Development	適用可能（ただし工夫が必要）	トランクベース開発では全ての開発者が単一のブランチで作業を行うため、ステージングや開発環境を模倣するためには特別な手法（例えば、フィーチャーフラグを用いて未完成の機能を隠すなど）が必要になります。

環境面に関して、GitHub FlowやTrunk-based Developmentでは、ブランチ戦略とは別のところで環境面の整理が必要になりそうです。

Git-Flowは一般的なWebアプリに対しては複雑なのか

残るは、Git-FlowとGitLab Flowです。 Git-Flowは2010年に「A successful Git branching model」に提唱されていますが、当該記事は2020年にNoteが付与されています。そこから一節を引用します。

During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

A successful Git branching model » nvie.com

一言で言えば、Webアプリは継続的に更新され複数バージョンを管理する必要がないため、Git-Flowよりもよりシンプルなワークフローが推奨されています。

また、もちろんポジショントークも含まれるのでしょうが、GitLabではProblems with the Git flowでGit-Flowの課題について言及しています。