はじめに

個人・チームの開発で Git を使ったバージョン管理を行っている人が多いと思います。

GitHub・GitLab・Bitbucket などの Git 管理サービスも充実していますよね。

今回はよりスマートに Git 運用を行なっていくための ブランチ戦略 についてお話ししていこうと思います。

ブランチ戦略って？

Git では、複数人が並行して作業を行うための ブランチ という機能が用意されています。

このブランチの運用規約をあらかじめ定めておき、その運用に則った開発を行うことを ブランチ戦略 と呼びます。

なんでブランチ戦略が必要なの？

ブランチを切ることで、他の人の作業に影響を与えず、また影響を受けずに実装を行いマージする、ということが可能になります。

しかし、Git ではブランチを切る際の制限が全く設けられていません。

そのため、誰でも自由に切ることができるという気軽さがある反面、ブランチが乱立することで、

「えっと、このブランチなんだっけ...？」

ってことが起こってきます。

個人開発では、それでも「まあ、いっか」と流せる場面も多いかもしれませんが、チーム開発や大規模開発になるとそうもいきません。

「どのブランチでリリース管理してるの？」

「どのブランチで次バージョンの開発やってるの？」

「どのブランチから作業ブランチ切ればいいの？」

「どのブランチにマージすればいいの？」

などの不透明な部分が増え、規模が大きくなればなるほど開発者間やプロジェクト上での運用事故が起きかねませんし、Git のバージョン管理ツールとしての恩恵を受けにくくなります。

そのため、これらを未然に防ぐために ブランチに関するルールを整備すること が必要になってくるのです。

どんなブランチ戦略があるの？

それでは、代表的なブランチ戦略のフローを見ていきましょう。

1. Git-flow
2. GitHub-flow
3. GitLab-flow

今回は以上3つのフローを取り上げます。

Git-flow

（引用: A successful Git branching model）

A successful Git branching model にて提案された記念すべき最初のフローの1つです。

develop ブランチで開発を進めていき、release ブランチでリリース作業を、完了したら master に格納されます。

基本運用フロー

1. master から develop を切る。
2. develop から feature を切り、機能開発を行う。
3. feature から develop へマージを行う。
4. develop から release を切り、バージョニングなどのリリース作業を行う。
5. リリースが完了したらタグ打ちを行い、release から master と develop へマージを行う。

緊急対応フロー

1. master から hotfix を切り、対応を行う。
2. hotfix でバージョニングなどのリリース作業を行う。
3. リリースが完了したらタグ打ちを行い、hotfix から master と develop へマージを行う。

メリット

1. 各ブランチの役割がはっきりしており、状況に応じて柔軟に対応することができる。
2. 各ブランチに対するメンバーの権限を適切に扱うことができる。
3. リリース管理が厳密に行える。
4. どのプロジェクトにも適用可能。

リリース作業を明確に release ブランチで行うため、リリース作業が必要なソフトウェア開発で適していますね。

全ての行程に対して十分な数のブランチが存在するため、最良とは言えませんが全てのプロジェクトに適用可能なフローです。

デメリット

1. 運用ブランチの数が多い。
2. 各ブランチのルールとフローが複雑。
3. プロジェクトによっては不要なブランチが存在する。（release や hotfix）

各ブランチを厳格に役割を持たせて運用するため、ルールやフローが複雑になり、学習コストや運用コストが高めなのがまずデメリットとして挙げられます。

それに付随して、Git を正しく理解し運用を行えないとフロー自体が破綻してしまう可能性が高くなってしまいますね。

ただ、逆に言うと本フローを運用できるようになれば、Git への理解が深まるとも言えます。

GitHub-flow

（引用: GitHub Flow - GitHub Docs）

GitHub が提唱した、Git-flow の複雑な点を解消したフローです。

master と feature しか存在しないシンプルなものになっているのが特徴ですね。

GitHub の創設の際にも採用されたフローで、多くの Web サービスで採用されています。

運用フロー

1. master から feature を切り、機能開発・緊急対応などを行う。
2. feature から master へマージを行う。
3. master のリリースを行う。

メリット

1. 高速でこまめなリリースが可能。
2. ブランチ同士のコンフリクトを最小限に抑えられる。
3. Git 初学者に易しく運用しやすい。

リリースまで複雑なフローが存在しないため、高速かつこまめにリリースを行えるのが大きな強みです。

そのため、スモールアップデートで保守運用を行う Web システム（SaaS）などに適しています。

運用ブランチが少ないためコンフリクトも発生しにくく、運用フローもシンプルなため Git 初学者や未学者でも理解しやすいものになっています。

デメリット

1. リリースのバージョン管理機能が存在しない。
2. リリースタイミングを調整できない。
3. ブランチに対してメンバーの権限を設定しづらい。
4. 対応可能なプロジェクトが限定される。

リリースのバージョン管理に関して明確な規約が存在せず、プロジェクト内で策定する必要が生じます。

また、master へマージされる度にリリースされるため、「複数対応をまとめてデプロイする」などといったリリースタイミングを任意に調整することができません。

運用ブランチが少ないことは各ブランチの責務が大きくなることに繋がるため、メンバーに応じた権限を明確に設定しづらいのもデメリットになります。

シンプルが故に、複数の開発ラインが走るようなプロジェクトには対応できないなど、採用可能なプロジェクトが限定されることもしばしばです。

GitLab-flow

（引用: Introduction to GitLab Flow | GitLab）

GitLab が提唱したフローで、前述の Git-Flow・GitHub-Flow を掻い摘んだようなものになっています。

GitHub-Flow にリリース管理機能を追加したようなイメージです。

運用フロー

1. master から feature（緊急対応時は hotfix） を切り、機能開発を行う。
2. feature から master へマージを行う。
3. master から pre-production を切り、リリース作業を行う。
4. リリースが完了したら（タグ打ちを行い）、pre-production から production へマージを行う。

メリット

1. 運用ブランチの数が比較的少なく、Git-Flow のように複雑でない。
2. Git-Flow ほど厳密ではないが、リリース管理を行うことができる。
3. 各ブランチに対するメンバーの権限を適切に扱える。

GitHub-Flow の開発からリリースまでのスピード感をできるだけ維持しつつ、Git-Flow のリリース管理を運用できるというのが大きなメリットですね。

また、開発・リリース管理と明確に役割がブランチが分かれていますので、Git-Flow のようにブランチ操作権限もメンバー毎に明確に与えることができます。

リリース作業が存在することを前提としているので、Git-Flow と同じくソフトウェア開発に向いていると言えます。

デメリット

1. GitHub-Flow ほどの開発からリリースまでのスピード感は出せない。
2. Git-Flow ほどの厳密なリリース管理やブランチ権限管理ができない。
3. 対応可能なプロジェクトが限定される。

前述した他2つのフローと比べて何かの機能に特化したものではありません。

GitHub-Flow のような高速リリースは実現できませんし、Git-Flow のような厳密なリリース管理が行えないので、上述したメリットがそのままデメリットになり得ます。

他のフローよりも、より一層プロジェクトのルールや特徴を良く把握した上で適用しないと、いいとこ取りでなく悪いとこ取りになってしまい、器用貧乏なフローになってしまう可能性があります。

結局どのブランチ戦略使えばいいの？

正解なんてないです！！

「何言っとんのやーーーー！！」と思う方もいるかもしれません（笑）

でも、上記3つのフローを一緒に見てきて気づいた人もいらっしゃると思いますが、それぞれにしっかり メリットとデメリットが存在するんですね。

ですので、自分が担当するプロジェクトがどのようなルールを持っているか？どのようなリリース管理体制になっているか？などによって、適したフローは変わってきます。

厳密にリリース管理・ブランチ権限管理を明確に行いたいのであれば Git-Flow が採用されるでしょうし、

SaaS だからスピード命！少人数だしそこまで厳密に管理する必要もないよ！であれば GitHub-Flow が採用されるでしょうし、

そこまで権限について気にする必要ないし、ある程度リリース管理できれば良いのであれば GitLab-Flow が採用されるでしょう。

もっと複雑な運用ルールに対応するために、提唱されているものから派生した独自のフローを立てているプロジェクトもあります。

フロー自体も正解があるわけではなく、あくまで ブランチ戦略の考え方の骨子である、ということですね。

さいごに

今回は代表的な3つのブランチ戦略のフローについて一緒に見てきました。

フローはプロジェクトの運用や特徴によって選ぶべきで正解はない、ということも分かっていただけたかと思います。

ブランチ戦略のフローはあくまで Git 管理を有効活用するための「手段」にすぎません。

プロジェクトの「目的」から適切なブランチ戦略を取れるようになることが一番大事だと思います。

まずは小さい個人開発からブランチ戦略を考えてみて、第一歩を踏み出してみましょう！

皆様の開発ライフがより豊かになりますように！

ご覧いただきありがとうございました！