そもそもブランチって何？

Gitにおけるブランチとは、開発現場では「作業の分岐」という意味を指します。
ブランチを作ることで、同じリポジトリ内で複数の作業を同時に行うことができます。
例えば、新機能の開発とバグ修正を同時に行いたい場合に、それぞれの作業をブランチに分岐して行うことができるので、作業同士が干渉することがありません。
開発をしている作業者同士が余計な確認をすることがなくなるので、開発効率が上がりますね〜。
また、各作業者のブランチをマージすることで、作業の成果を他のメンバーと共有することができます。

ブランチ戦略とは？

ブランチ戦略とは、ブランチを作るときのルールを指します。
（例えば、ブランチの名前をつけるときに、どのようなルールを決めるか？など）
前述しましたが、ブランチを作ることによって開発者同士が干渉することなく、開発を行うことができます。

しかし、ブランチを作る際の制限はありません。
気軽に自由にブランチを作ることができるので、皆が好き放題にブランチを作ってしまうと管理が大変になってしまいます。
そこで、あらかじめブランチ戦略を決めておくことでバージョン管理や進行状況の把握がしやすくなります。

ブランチ戦略の種類

ブランチ戦略をゼロから作ることは大変です。
まずは、既に作られているものを参考にして、自分たちのチームにあったブランチ戦略を採用しましょう。

Gitブランチ戦略マクロ解説では、以下の6種類の代表的なブランチ戦略を解説していこうと思います。

• git-flow
• GitHub Flow
• GitLab Flow
• Trunk-based Development
• mainline development

git-flowとは？

git-flowは、Vincent Driessenによって提唱されたブランチ戦略です。
主に、大規模な開発プロジェクトで使用されます。
ブランチ戦略といえばこれ！というくらい知名度が高く、多くの開発現場で採用されています。

git-flowの特徴

git-flowでは、以下の画像ようなブランチ管理を行います。



これら合計5つのブランチには、それぞれ以下のような役割があります。

main

mainは、リリースされたコードが管理されるブランチです。
このブランチでは基本的にコードの修正を行わず、リリースされたコードのみを管理します。

develop

developは、開発中のコードが管理されるブランチです。
後述するfeatureからマージされたコードが管理されます。

feature

featureは、新機能の開発を行うブランチです。
開発者は、このブランチで新機能の開発を行い、開発が完了したらdevelopにマージします。

release

releaseは、リリース前のテストを行うブランチです。
このブランチではリリース時のバージョン調整やドキュメントの更新、バグデバッグなどのリリースに伴うタスクのみを実行します。
リリース対象の作業が完了しリリース準備が整い次第、mainへマージします。

hotfix

hotfixは、リリース後に発生したバグを修正するブランチです。
リリースされている最新のmainをベースに作成します。
バグの修正が完了したら、mainにマージします。

運用ルール

git-flowでは、以下のような運用ルールがあります。

developは常に最新のmainから作成

developは常に最新のmainから作成されている状態を保つ必要があります。
例えばreleaseやhotfixで作業があった際は、そちらの変更点をdevelopにも反映させる必要があります。
後述につながりますが、最新のmainとdevelopに差があると、作業を行うfeatureで矛盾が起きますよね？

featureはdevelopから作成

featureは常に最新のdevelopから作成する必要があります。
「新機能を開発する時はとりあえずdevelopから切る」を心がければ良いと思います。
場面によっては親となるfeatureを作って、その中に機能追加のfeatureを作る~なんてこともあります。
余談なのであまり気にしないでください。

releaseはdevelopから作成

releaseはリリース対象の作業が反映された最新状態のdevelopをベースに作成します。
リリース対象の作業が完了しリリース準備が整い次第、mainにマージします。
また、リリース後はリリースに伴った作業を反映させるため直接developへマージすることもあります。

hotfixはmainから作成

リリース後に見つかったバグを修正するため、常に最新のmainから作成します。
バグの修正が完了したら、mainにマージします。

マージ済みのfeatureブランチは削除

マージ済みのfeatureブランチは、mainにマージされた後は不要なので削除します。
削除し忘れるとたくさん溜まってブランチの数がとんでもないことになるので気をつけましょう。
消し忘れても手動で削除することは可能です。

メリット

git-flowのメリットは以下のような点があります

品質が保証される

mainが常に最新の状態で保たれるため、リリース時のバージョン調整やドキュメントの更新、バグデバッグなどのリリースに伴うタスクのみを実行することができます。

リリース履歴がシンプルになる

mainは原則、releaseからマージされるため履歴がシンプルになります。
これにより、mainの履歴を見ただけで、リリースされたコードの履歴を確認することができます。

リリース準備と後続の開発を同時に行える

releaseでリリース準備を行うため、featureで引き続き後続の開発を行うことができます。
リリース準備の作業に怯えずに開発を進めることができるのでエンジニアファーストですね！

スピーディなバグ修正

hotfixを用意しているため、リリース後に発生したバグを他のブランチへ影響することなく迅速に修正することができます。
releaseと同じくエンジニアファーストな考え方ですね！

多くの現場で採用されている

git-flowは多くの現場で採用されているため、メンバー同士のコミュニケーションが取りやすいです。
GUIツールもgit-flowに対応しているものが多いです。

※GUIツール・・・sourceTree, GitHub Desktop, GitKrakenなど

デメリット

git-flowには無視できないデメリットも存在し、特に以下のような点を感じます。

複雑化しやすい

git-flowのフロー自体が複雑なことで、運用方法を覚えるのに時間がかかることがあります。

CI/CDツールの導入が難しい

git-flowは、複数のブランチからマージが集中する構造なために、サーバへの負荷が膨大になることでツールの動作が重くなる可能性があります。
（特にdevelopブランチはfeature/release/hotfixの三箇所からマージされる。）
また、別のブランチで新しい変更があった際、ツールがデプロイ中だとそれらの変更がマージできない可能性もあります。
また、フローが複雑な構造のため、設定ミスを起こすリスクがあるのも懸念点として挙げられます。

ブランチ数が多い

git-flowでは、ブランチの数が多いためマージのタイミングを間違える可能性があります。
また、プロジェクト人数が増えるたびに、ブランチへのアクセスロールを考える必要があり複雑になることがあります。
そしてその分レビューの対象も多くなるため、レビューが大変になることがあります。

まとめ

git-flowは、「ブランチ戦略といえばこれ！」というくらい知名度が高いので、まずはこれを試してみるのがおすすめです。
メリットとデメリットを享受できるようになれば、自分たちのチームにあったブランチ戦略を選択できるようになります。
ともあれ、git-flowは複雑かつ面倒なことも多いので、のちにコラム化する別のブランチ戦略を実用するのが良いかもしれません。

次回は「GitHub Flow」について解説します。
それでは、また1ヶ月先でお会いしましょう！

参考文献

• git-flow