git-flow 図解

git-flow is 🤔

• Vincent Driessen さんがブログで公開した A successful Git branching model のこと
  • 元記事：A successful Git branching model
  • 日本語訳： A successful Git branching model を翻訳しました
• または、A successful Git branching modelを補助するためのツールの名称
  • git-flow cheatsheet
• ブランチの運用ルール、命名規則を設けることで、
  複数人開発時も各ブランチをわかりやすい状態に保つことができるようになる
• もっとシンプルなルールにしたものに、GitHubFlowがある
  • 元記事：GitHub Flow
  • 日本語訳：github-flow.ja.md
  • 小さなサイクルでデプロイするケース向き

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

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

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

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

hotfix ブランチ

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

運用手順

develop を作成する

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

機能開発の準備を行う

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

機能開発を行う

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

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

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

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

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

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

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

リリース完了

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

緊急修正対応を行う

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

緊急修正対応を完了する

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

まとめ

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