📕

git-flow 図解

4 min read

git-flow is 🤔

  • Vincent Driessen さんがブログで公開した A successful Git branching model のこと
  • または、A successful Git branching modelを補助するためのツールの名称
  • ブランチの運用ルール、命名規則を設けることで、
    複数人開発時も各ブランチをわかりやすい状態に保つことができるようになる
  • もっとシンプルなルールにしたものに、GitHubFlowがある

この記事では、A successful Git branching modelに登場するブランチについて説明していきます。

利用する 5 種類のブランチの前に、運用手順に目を通したほうがイメージが付きやすいかもしれません m(_ _)m
個人的な意見には、先頭に 🤔 を入れています。

利用する 5 種類のブランチ

image.png

git-flow は 2 種類のメインブランチ ( master , develop ) と 3 種類のサポートブランチ ( feature , release , hotfix )を利用します。

メインブランチ

開発のとなるブランチ

master ブランチ

  • 分岐元:なし
  • マージ先:なし
  • ブランチ名の例:master
  • 特徴
    • 本番にリリースできる状態を保つ
    • 直接コミットは行わない
    • release 、hotfix からマージを行い、タグを作成する
      • 🤔 タグ名は release/vX.X.X がよいと思う

develop ブランチ

  • 分岐元:master
  • マージ先:なし
  • ブランチ名の例:develop
  • 特徴
    • 開発中の最新状態を反映する
    • 基本、直接コミットは行わない
    • feature , hotfix からマージを行う

サポートブランチ

メインブランチでの開発を補助するためのブランチ

feature ブランチ

  • 分岐元:develop
  • マージ先:develop
  • ブランチ名の例:他のブランチ名のルールと重複しないもの
    • 🤔 シンプルに feature/* か、
        feature/YYYYMM_{案件名}/* とかするのがいいと思う
    • 🤔 Github などを用いて issue と合わせて運用するのであれば、
        feature/{issue番号}__* とか、feature/YYYYMM_{案件名}/{issue番号}__* としたほうがいいと思う
  • 特徴
    • 新機能の開発を行うのに用いる
    • develop へマージする際は、Git の -no-ff オプションも活用する
      (一連のコミットを 1 コミットにまとめる機能)
    • リモートへ Push せず、ローカルでのみ利用する
      • 🤔 Pull Request も活用するのであれば、Push してもいいと思う

release ブランチ

  • 分岐元:develop
  • マージ先:masterdevelop
  • ブランチ名の例:release-*
    • 🤔 release/vX.X.X がいいと思う
  • 特徴
    • リリースの準備作業を行うのに用いる
      • バージョンの変更
      • 小さなバグフィックス
    • master へマージ後、 develop へマージする
      完了後、release を削除する

hotfix ブランチ

  • 分岐元:master
  • マージ先:masterdevelop
  • ブランチ名の例:hotfix-*
    • 🤔 hotfix/* がいいと思う
    • 🤔 Github などを用いて issue と合わせて運用するのであれば、
        hotfix/{issue番号}__* としたほうがいいと思う
  • 特徴
    • 緊急のバグフィックスを行うのに利用する
    • master へマージ後、develop へマージする
      完了後、hotfix を削除する
      • 利用用途としては release に似ているが、
        develop を経由せずに master へマージできるため
        進行中の開発が影響を受けにくい

運用手順

develop を作成する

image.png

  1. master から develop を作成する
    リポジトリ作成直後のみ実施する

機能開発の準備を行う

image.png

  1. develop から feature を作成する
    feature は開発する機能毎に作成する

機能開発を行う

image.png

  1. feature で機能を開発する
    ローカルでのみコミットし、push は行わない
    🤔 後で feature を削除するのであれば、Push してかまわないと思う
    🤔 Push すれば、WIP Pull Requestや Github のDraft Pull Requestが利用できる

開発中の最新状態を feature に取り込む

image.png

  1. 任意のタイミングで developfeature へマージする
    マージ時のコンフリクトを避けるため

開発済みの機能を develop へ取り込む

image.png

  1. featuredevelop へマージする
    🤔 Github などを利用している場合は、PR(Pull Request)を利用する

リリース作業の準備を行う

image.png

  1. リリース準備のため、develop から release を作成する
  2. release でバージョンの変更や、小さなバグフィックスを行う

リリース完了

image.png

  1. releasemaster へマージし、タグを作成する
  2. 製品をリリースする
  3. releasedevelop へマージする
  4. release を削除する

緊急修正対応を行う

image.png

  1. master から hotfix を作成する
  2. hotfix でバグフィックスやバージョンの変更を行う

緊急修正対応を完了する

image.png

  1. hotfixmaster へマージし、タグを作成する
  2. 製品をリリースする
  3. hotfixdevelop へマージする
  4. hotfix を削除する

まとめ

オリジナルの概念が発表されたのが、既にかなり前になります。
現在は Github などで様々な機能もできていますので、feature は PUSH してしまったほうが、
Draft PR (WIP PR)によるレビューや作業状況の把握のためよいと思います。
また、オリジナルは使い終わったブランチは基本的に削除する方針ですが、
後続の開発の邪魔にならないようにブランチ名のルールを決めていけば、
残しておいてもいいと思います。

GitHubで編集を提案

Discussion

ログインするとコメントできます