486
480

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

git-flow 図解

Last updated at Posted at 2020-04-24

git-flow is :thinking:

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

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

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

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

image.png

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

メインブランチ

開発のとなるブランチ

master ブランチ

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

develop ブランチ

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

サポートブランチ

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

feature ブランチ

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

release ブランチ

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

hotfixブランチ

  • 分岐元:master
  • マージ先:masterdevelop
  • ブランチ名の例:hotfix-*
    • :thinking: hotfix/* がいいと思う
    • :thinking: 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は行わない
    :thinking: 後で feature を削除するのであれば、Pushしてかまわないと思う
    :thinking: Pushすれば、WIP Pull RequestやGithubのDraft Pull Requestが利用できる

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

image.png

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

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

image.png

  1. featuredevelop へマージする
    :thinking: 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)によるレビューや作業状況の把握のためよいと思います。
また、オリジナルは使い終わったブランチは基本的に削除する方針ですが、
後続の開発の邪魔にならないようにブランチ名のルールを決めていけば、
残しておいてもいいと思います。

486
480
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
486
480

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?