Gitブランチ戦略とは？(feat. Git Flow, Github Flowについて)

チームメンバーとプロジェクトを進める中で直面する問題があります。それはブランチです！

ブランチとは？

ブランチ戦略について話す前に、まず、ブランチとは何かについて整理する必要がありそうです。私たちはなぜブランチを使うのでしょうか？ブランチを追加で作成せず、作業をメインブランチだけで進めればどうなるでしょうか？メインブランチ1つに頼って多くの開発者が協力すれば、自分が作業しているファイルを他の誰かが触ることができるようになります。また、色んな機能を開発しながら残されたコミット履歴がメインブランチに混ざってしまいます。コミット履歴が混在してしまうと、企画変更で開発中の機能が不要になったときや、問題が発生したときに目的の時点にロールバックすることも難しくなります。😇

ブランチ機能を使うと、他のブランチの影響を受けない独立した環境で機能を開発したり、バグを修正することができます。まるでプロジェクトフォルダをコピーして、コピーしたフォルダで別々に作業しているようなものです。つまり、複数の機能を複数の人が並行して開発できるようになります！

機能を開発する時、ブランチを生成し、コードを書いてコミットを残します。その後、機能開発が完了した後、メインブランチにマージすれば安全に機能を開発することができます。このようなブランチを使って新しい機能を開発し、企画が変更されて機能が不要になった時も、簡単にブランチを削除すれば終わりです。

Gitブランチ戦略

このような良いブランチも、ルールなしで乱用すると混乱を招く可能性があります！ブランチ管理に明確な基準がないと「このブランチは何の目的で生成されたのか」、「このブランチはどのコミットから分岐したのか」、「どのブランチから自分のブランチを生成するのか」、「自分のブランチはどこにマージするのか」、「どのブランチが最新なのか」、「どのブランチが配布されているバージョンなのか」など多くの疑問が発生し、プロジェクトは混乱する可能性があります。

Gitブランチ戦略はプロジェクトのGitブランチを効果的に管理するためのワークフローです。直接ブランチ戦略を作って使うこともできますが、デザインパターンのようにブランチを効果的に管理するためのパターンが存在します。このポストでは色んなパターンの中でGit Flow、Github Flowについてまとめてみます。

Git Flow

Git FlowはVincent Driessenという人が2010年に投稿したA successful Git branching modelという記事が人気となり一般的に採用されたブランチ戦略です。

Git Flowは大きくMainブランチ、Developブランチ、Supportingブランチに分けてブランチを管理します。Supportingブランチはまた、Featureブランチ、Releaseブランチ、Hotfixブランチに分けて管理します。

MainブランチとDevelopブランチは開発プロセス全体を通じて常に維持されるブランチです。一方、Supportingブランチは必要な時に作成され、役割を終えたら削除することを原則とします。Supportingブランチのおかげでチームで並列的にプロジェクトを進めることができるようになります。それでは、各ブランチについてもっと詳しく説明します！

Mainブランチ

Mainブランチはリリース可能なプロダクションコードをまとめておくブランチです。Mainブランチはプロジェクト開始時に生成され、開発プロセス全体を通して維持されます。配布された各バージョンをTagを使って表示します。

Developブランチ

Developブランチは次のバージョン開発のためのコードをまとめておくブランチです。開発が完了したら、Mainブランチにマージされます。

Featureブランチ

Featureブランチは一つの機能を開発するためのブランチです。Developブランチで生成し、機能開発が完了したら、再びDevelopブランチにマージされます。マージする時注意点はFast-Forwardでマージせず、Merge Commitを生成してマージする必要があります！このように進めないと、ヒストリーが特定の機能単位にまとめられます。

ネーミングは主にfeature/branch-nameのような形で作成します。

Releaseブランチ

Releaseブランチはソフトウェア配布を準備するためのブランチです。Developブランチで生成し、バージョン名などの細かいデータを修正したり、デプロイ前に細かいバグを修正するために使います。配布の準備が完了したら、Main、Developブランチに両方マージします。この時、Mainブランチにはタグを使ってバージョンを表示します。

Releaseブランチを別に運用することで、配布業務に関係ないチームメンバーは並行してFeatureブランチで機能を開発することができます。

ネーミングはrelease/v1.1のような形で作成します。

Hotfixブランチ

Hotfixブランチは既に配布されたバージョンに問題が発生した時、Hotfixブランチを使って問題を解決します。Mainブランチで生成し、問題解決が終わったらMain, Developブランチに両方マージします。

Releaseブランチと同様にHotfixブランチを別に運用することで、Hotfix業務と関係ないチームは並行して機能開発をすることができます。

ネーミングはhotfix/v1.0.1と同じ形で作成します。

Git Flowの限界：ウェブアプリケーションには不向き

Git Flowについて書いたVincent DriessenはGit branching modelを作成してから10年経った2020年、そのポストの上に反省の記事(Note of Reflection)を書いています。その内容をまとめると次のようになります。

Git-Flowは登場してから10年以上、標準のように定着し、さらに万能薬のように使われてきました。現在は、Gitで管理される人気のあるタイプのソフトウェアがWebアプリケーションに移行しています。Webアプリケーションは一般的にロールバックされず、継続的に提供(Continuous Delivery)されるため、複数のバージョンのソフトウェアをサポートする必要がありません。

つまり、Git Flowは明示的にバージョン管理が必要な例えば、スマートフォンアプリケーション、オープンソースライブラリ/フレームワークなどのプロジェクトに適しています。韓国で有名なポストであるエレガント兄弟の技術ブログの私たちはGit-flowを使っていますの記事を書いたチームもアンドロイドアプリ開発チームです。

Webアプリケーションの特性上、ユーザーは常に最新の単一バージョンのみを使用することになります。複数のバージョンを並列的にサポートする必要がないのです。また、Webアプリケーションは一日に何度もリリースされることがあります。このような特性のため、Webアプリケーション開発にGit Flowはあまり適していません。

実際、プロジェクトを進めながら一番人気のあるGit Flowを採用しましたが、ReleaseとHotfixブランチの必要性を、MainとDevelopブランチは一体なぜ区別するのか理解できませんでした。今まで考えてみると、ウェブアプリケーションだけ開発してきたからできた考えだと思います。

Github Flow

先に説明したGit Flowはほとんどのケースで複雑です。機械的にルールに従うだけなら大きな問題はないと言われますが、結局複雑なので多くの人(術者を含む)が失敗して迷うことになります。Github FlowはこのようなGit Flowとは違ってすごくシンプルな構造です。

Github Flowは名前の通りGithub環境で使うのに適したブランチ戦略でもあります。また、自動化を積極的に活用することもできます。

Mainブランチ

Mainブランチは常にStableな状態でなければなりません。ここで、Stableというのは、Mainのすべてのコミットはいつ配布しても問題なく、いつでもブランチを新しく作っても問題ないことを意味します。Mainブランチの全てのコミットはビルドされ、テストに合格しなければなりません。これがGithub Flowが強制する唯一の事項です。

Topicブランチ

新しい機能を開発する時はMainブランチからTopicブランチを生成します。Git FlowのFeatureブランチと同じ役割をします。また、別途Hotfixブランチを生成せず、バグ修正もTopicブランチで行います。

この時、Topicブランチの名前は機能を説明する明確な名前をつける必要があります。例えば、user-cache-key、submodules-init-task、redis2-transitionなどがあります。

Topicブランチのコミットは機能が完成していなくても継続的にPushします。ノートパソコンの紛失、作業パソコンの故障などのリスクでコードが流失するのを防いでくれます。これよりもっと重要な理由は、継続的にPushすることで、メンバー全員が常にコミュニケーションができるようになります。

GithubにはPR(Pull Request)という便利な機能があります。開発者は機能を開発中、いつでもPRを開設することができます。コードの変更がなくても、スクリーンショット、アイデアを共有したい時にもPRを開設します。開発者たちは開設されたPRで議論をし、コードの特定のラインを選択してコメントを残してコードレビューをやり取りします。

議論とレビューが終わったら、他の人の同意(Approve)を得て、Mainブランチに自分のTopicブランチをマージします。ただし、この時、Topicブランチは自動化されたCIビルドを通過しなければマージができません。