PJMプロジェクト管理合同会社 お問い合わせ

公式SNS

PJM Project Management お問い合わせ

公式SNS

お知らせ

Gitのブランチ戦略について調べてみた

ブログ

チーム開発において、Gitを使用したソースコードのバージョン管理を行っている方が多いと思います。

今回、Git運用を行なっていくための「ブランチ戦略」について調べてみました。

ブランチ戦略とは？

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

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

ブランチ戦略の必要性

ブランチを切る（ひとつのプロジェクトから枝分かれをさせ、別の作業を行う）ことで、他の人の作業に影響を与えず、また影響を受けずに作業を行ってマージ（統合）する、ということが可能になります。

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

つまり、誰でも自由にブランチを切ることができますが、ブランチが乱立することで、不透明な部分が増え、規模が大きくなればなるほど開発者間やプロジェクト上での運用事故が発生しやすくなります。

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

代表的なブランチ戦略

代表的なブランチ戦略の3つを紹介します。

  • Git-flow
  • GitHub-flow
  • GitLab-flow

Git-flow

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

一番中心になるメインブランチはmasterブランチとdevelopブランチです。

そして、メインブランチをサポートするブランチとしてfeatureブランチ、releaseブランチ、hotfixブランチがあります。

各ブランチの定義

  • masterユーザにプロダクトとしてリリースするソースコードを管理するブランチ
  • develop現在開発中のソースが格納されるブランチ
  • feature新しい機能を開発するブランチ
  • releaseリリース直前にバグ修正などの微調整を行うブランチ
  • hotfixリリースされたバージョンで発生したバグを速やかに修正するブランチ

基本運用フロー

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

メリット

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

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

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

デメリット

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

各ブランチを厳格に役割を持たせて運用するため、ルールやフローが複雑になり、Gitの学習コストや運用コストが高いです。

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

GitHub-flow

Git-flowをよりシンプルにしたのがGitHub-flowです。

GitHub-flowでは、masterブランチとfeatureブランチしか使わないため、Git-flowと比較してわかりやすいフローとなっています。

全てをmasterブランチにマージし、こまめにデプロイすることで、デプロイ待ちのコードの量を最小限にできます。

各ブランチの定義

  • master最新リリースのソースが格納されるブランチ
  • feature開発作業を行うブランチ

基本運用フロー

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

メリット

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

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

スモールアップデートで保守運用を行う Web システム（SaaS）などに適しているフローです。

また、運用フローもシンプルなため Git初学者でも理解しやすいものになっています。

デメリット

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

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

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

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

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

GitLab-flow

GitHub-Flow にリリース管理機能を追加したのが、GitLab-flowです。

GitHub-flowにproductionブランチ、pre-prooductionブランチを追加し、この2つをメインブランチとします。

各ブランチの定義

  • productionリリース済のソースが格納されるブランチ
  • pre-prooductionバージョニングなどのリリース作業を行うブランチ
  • master開発中のソースが格納されるブランチ。
  • feature開発作業を行うブランチ

基本運用フロー

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

メリット

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

GitHub-Flow の開発からリリースまでのスピード感をできるだけ維持しつつ、Git-Flow のリリース管理を運用できます。

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

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

デメリット

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

前述した他2つのフローと比べて、特化したものがありません。

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

まとめ

今回はブランチ戦略の概要と、代表的な3つのブランチ戦略のフローについて紹介しました。

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

プロジェクトの「目的」から、適切なブランチ戦略を取れるようになることが重要です。

ご参考になれば幸いです。