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 の概要は以下のとおりです。
develop
ブランチはmaster
から作成されるrelease
ブランチはdevelop
から作成されるfeature
ブランチはdevelop
から作成される- 完了した
feature
はdevelop
ブランチにマージされる - 完了した
release
ブランチはdevelop
とmaster
にマージされる master
で問題が検出されるとhotfix
ブランチがmaster
から作成される- 完了した
hotfix
はdevelop
とmaster
の両方にマージされる
次はフォーク型ワークフローについて学習するか、ワークフロー比較ページにアクセスしてください。