Gitflow ワークフロー

Gitflow ワークフローは、nvie のVincent Driessen 氏が初めて公開して有名になった Git ワークフローのデザインです。Gitflow ワークフローは、プロジェクトのリリースに関連した利用を想定して設計された厳密なブランチモデルを定義します。大規模プロジェクト管理が可能な強固なフレームワークを提供します。

Gitflow はリリースサイクルがあらかじめ決まっているプロジェクトに最適です。このワークフローでは、フィーチャーブランチワークフローに使用されているもの以外の概念や命令は必要としません。その代わり、異なるブランチに対して個別にロールを割り当て、それらが相互に作用する手順や条件を定義します。また、フィーチャーブランチに加え、リリースの準備、保守、記録を行うためにそれぞれのブランチを使用します。言うまでもなくプルリクエストや隔離実験等のフィーチャーブランチワークフローのすべての特長を利用でき、コラボレーションのさらなる効率化が実現できます。

はじめに

Gitflow は、まさに Git ワークフローの抽象的なアイデアだと言えます。つまり、Gitflow には設定するブランチとそのマージ方法が記載されています。ここからは各ブランチの目的について説明していきます。git-flow ツールセットはインストールプロセスを備えた実用的なコマンドラインツールです。git-flow のインストールプロセスはシンプルで、複数の OS 用の git-flow パッケージが用意されています。OSX システムでは brew install git-flow を実行します。Windows では git-flow をダウンロードしてインストールする必要があります。git-flow をインストールしたら、git flow init を実行してプロジェクトで git-flow を使用できます。Git-flow は Git のラッパーです。git flow init コマンドはデフォルトの git init コマンドのエクステンションで、ブランチの作成を除いてリポジトリ内を変更することはありません。

仕組み

develop ブランチと master ブランチ

このワークフローでは、1 つの master ブランチだけではなく、プロジェクトの履歴を記録するために 2 つのブランチを使用します。master ブランチは公式のリリース履歴を保管し、develop ブランチはフィーチャー組み込みブランチとしての役割を持ちます。また、master ブランチにすべてのコミットをバージョン番号つきでタグ付けするのが便利です。

最初のステップは、デフォルトの master に対して develop ブランチを作成することです。これを行う簡単な方法は、1 人の開発者が空白の develop ブランチをローカルに作成して、それをサーバーに送ることです。

 git branch develop git push -u origin develop

master には要約版が保管されるのに対し、このブランチにはプロジェクトの全履歴が保管されます。この時点で他の開発者は、セントラルリポジトリを複製し、開発用のトラッキングブランチを作成します:

git-flow エクステンションライブラリを使う際は、既存のリポジトリで git flow init を実行して develop ブランチを作成します。

 $ git flow init Initialized empty Git repository in ~/project/.git/ No branches exist yet. Base branches must be created now. Branch name for production releases: [master] Branch name for "next release" development: [develop]
 How to name your supporting branch prefixes? Feature branches? [feature/] Release branches? [release/] Hotfix branches? [hotfix/] Support branches? [support/] Version tag prefix? []
 $ git branch * develop master

フィーチャー ブランチ

すべての新規フィーチャーはそれぞれのブランチにおいて開発されますが、それをバックアップとコラボレーションのためにセントラルリポジトリに送ることが可能です。ただし、feature ブランチは master からブランチオフするのではなく、develop を親ブランチとします。フィーチャーが完成した時点で、develop にマージして戻します。フィーチャーは、master と直接作用してはなりません。

なお、feature ブランチおよび develop ブランチの組み合わせは、まさにフィーチャーブランチワークフローそのものです。しかしながら、Gitflow ワークフローには他にも多くの機能があります。

feature ブランチは通常、最新の develop ブランチに関連付けられます。

フィーチャーブランチの作成

git-flow エクステンションなし:

 git checkout develop git checkout -b feature_branch 

git-flow エクステンションあり:

git flow feature start feature_branch

作業を続行していつも通り Git を使ってください。

フィーチャーブランチの仕上げ

フィーチャーの開発作業が完了したら、次は feature_branch を develop にマージします。

git-flow エクステンションなし:

git checkout develop git merge feature_branch

git-flow エクステンションあり:

git flow feature finish feature_branch

リリース ブランチ

develop においてフィーチャーがリリース可能であると確認できた場合 (あるいはリリース予定期日が近くなった場合)、develop から release ブランチを分岐させます。このブランチの作成により、新たなリリースサイクルが開始されます。従ってこの時点以降は新規フィーチャーを付加できず、このブランチにおいてはバグ修正、ドキュメント生成、およびその他のリリースに伴うタスクのみが可能です。供用準備が完了すると、release ブランチは master にマージされ、バージョン番号つきでタグ付けされます。さらにリリース作成以降の進捗が反映された develop にマージして戻します。

このようなリリース専用ブランチを利用することにより、あるチームでは進行中のリリース準備を行いつつ他のチームでは次のリリースに向けたフィーチャー開発を同時に行うことが可能となります。またこの機能により開発のフェーズをより明確にできます (たとえば、「今週はバージョン 4.0 の作業をする」と明確に定義できると同時に、それがリポジトリの実際の構造に反映されます)。

シンプルなブランチング操作としては release ブランチの作成もあります。feature ブランチ同様、release ブランチも develop ブランチをべースにしています。新規の release ブランチを作成する方法は以下のとおりです。

git-flow エクステンションなし:

git checkout develop git checkout -b release/0.1.0

git-flow エクステンションあり:

$ git flow release start 0.1.0 Switched to a new branch 'release/0.1.0'

リリース準備が完了すると、master および develop にマージし、release ブランチは削除します。ここで develop ブランチにもマージして戻すことが重要です。これは release ブランチには重要な更新が加えられている可能性があり、そのような重要な更新に開発者がアクセスできるようにするためです。所属組織がコードレビューを重視している場合は、この時点でプルリクエストを送るべきです。

以下の方法で release ブランチを仕上げます。

git-flow エクステンションなし:

 git checkout master git merge release/0.1.0

git-flow エクステンションあり:

 git flow release finish '0.1.0'

hotfix ブランチ

メンテナンスブランチは、“hotfix”ブランチとも呼ばれますが、供用中のリリースに対して急いでパッチを当てて修正する場合に使用します。hotfix ブランチは、develop ではなく master をベースにしている点を除いて release ブランチと feature ブランチによく似ています。hotfix ブランチは master から直接分岐する唯一のブランチです。修正が完了した場合、直ちに master および develop の両方に (あるいは進行中の release ブランチに) マージされ、master は更新されたバージョン番号つきでタグ付けされます。

バグ修正専用の開発ラインを備えることにより、開発チームはワークフローの他の部分と干渉することなく問題に対応することが可能となり、修正のために次のリリースサイクルを待つ必要もなくなります。メンテナンスブランチを、master と直接作用する一時的 release ブランチとみなすこともできます。hotfix ブランチは以下の方法で作成できます。

git-flow エクステンションなし:

 git checkout master git checkout -b hotfix_branch

git-flow エクステンションあり:

 $ git flow hotfix start hotfix_branch

release ブランチの仕上げ同様、hotfix は master と develop の両方にマージされます。

 git checkout master git merge hotfix_branch git checkout develop git merge hotfix_branch git branch -D hotfix_branch

 $ git flow hotfix finish hotfix_branch

例

フィーチャーブランチフローの詳細な例は以下のとおりです。この例では、master ブランチを設定したリポジトリがあると仮定しています。

git checkout master
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout master
git merge develop
git branch -d feature_branch

feature フローと release フローに加え、hotfix の例を以下に示します。

 git checkout master git checkout -b hotfix_branch # work is done commits are added to the hotfix_branch git checkout develop git merge hotfix_branch git checkout master git merge hotfix_branch

概要

ここでは Gitflow ワークフローについて説明しました。Gitflow は数多くある Git ワークフローのなかでも開発者と開発チームが利用できるスタイルの 1 つです。

Gitflow の主なポイントは以下のとおりです。

• リリースベースのソフトウェアワークフローに最適である。
• 供用へのホットフィックス専用チャネルになる。
  

Gitflow の概要は以下のとおりです。

1. develop ブランチは master から作成される
2. release ブランチは develop から作成される
3. feature ブランチは develop から作成される
4. 完了した feature は develop ブランチにマージされる
5. 完了した release ブランチは develop と master にマージされる
6. master で問題が検出されると hotfix ブランチが master から作成される
7. 完了した hotfix は develop と master の両方にマージされる

次はフォーク型ワークフローについて学習するか、ワークフロー比較ページにアクセスしてください。