Close

Gitflow ワークフロー

Gitflow とは、元来は Git ブランチを管理するための破壊的で斬新な戦略のレガシー Git ワークフローです。Gitflow の需要は落ち込み、トランク ベースのワークフローが利用されるようになっています。現在ではこれが最新の継続的なソフトウェア開発のベスト プラクティスおよび DevOps プラクティスと見なされています。Gitflow はまた、CI/CD と使用することも困難な場合があります。この投稿では、歴史的な目的で Gitflow の詳細をご説明します。


Gitflow とは?


Gitflow とは、フィーチャー ブランチと複数のプライマリ ブランチを使用する代替 Git ブランチ モデルです。nvie の Vincent Driessen 氏が初めて公開して有名になりました。トランク ベース開発と比較して、Gitflow には永続的なブランチと大規模なコミットがあります。このモデルでは、開発者はフィーチャー ブランチを作成して、フィーチャーが完成するまでメインのトランク ブランチへのマージを延期します。これらの永続的なフィーチャー ブランチでは、マージにはより多くのコラボレーションが必要となり、トランク ブランチから逸脱するリスクが高くなります。また、アップデートの競合の原因にもなります。

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

コンソール・ウィンドウ
関連資料

高度な Git ログ

Bitbucket ロゴ
ソリューションを見る

Bitbucket Cloud での Git の使用方法についてのチュートリアルです。

仕組み


Git ワークフロー

develop ブランチと main ブランチ

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

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

git branch develop
git push -u origin develop

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

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: [main]
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
 main

フィーチャー ブランチ


ステップ 1. リポジトリの作成

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

Git ワークフロー:フィーチャー・ブランチ

なお、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_branchdevelop にマージします。

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

git checkout develop
git merge feature_branch

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

git flow feature finish feature_branch

リリース ブランチ


Git ワークフロー:リリース・ブランチ

develop においてフィーチャーがリリース可能であると確認できた (あるいはリリース予定期日が近くなった) 場合は、develop から release ブランチを分岐させます。このブランチを作成すると新たなリリース サイクルが開始されるため、この時点からは新規フィーチャーを追加できません。このブランチにおいては、バグ修正、ドキュメント生成、その他のリリースに伴うタスクのみを実行できます。リリースの準備が整うと、release ブランチは main にマージされてバージョン番号でタグ付けされます。さらに、リリース作成以降の進捗が反映された 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'

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

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

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

git checkout main
git merge release/0.1.0

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

git flow release finish '0.1.0'

hotfix ブランチ


git ワークフロー内の Hotfix ブランチ

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

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

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

git checkout main
git checkout -b hotfix_branch

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

$ git flow hotfix start hotfix_branch

release ブランチの仕上げと同じように、hotfix ブランチは maindevelop の両方にマージされます。

git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch
$ git flow hotfix finish hotfix_branch


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

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

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

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

要約


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

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

  • このワークフローは、リリースベースのソフトウェア ワークフローに最適です。
  • Gitflow は、hotfix の本番専用チャンネルを提供しています。

Gitflow の全体的な流れは次のとおりです。

1. develop ブランチは main から作成されます

2. release ブランチは develop から作成されます

3. feature ブランチは develop から作成されます

4. feature が完成した時点で、develop ブランチにマージされます。

5. release ブランチが完成すると、developmain にマージされます

6.main に問題が検出されると、hotfix ブランチが main から作成されます

7. hotfix が完了すると、developmain の両方にマージされます

次はフォーク型ワークフローについて確認するか、ワークフロー比較ページに進んでください。


この記事を共有する

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

一面のツールを使ってコラボレーションしている人たち

Bitbucket ブログ

DevOps のイラスト

DevOps ラーニング パス

Demo Den アトラシアン・エキスパートによる機能デモ

Bitbucket Cloud が、Atlassian Open DevOps とどのように連携するか

DevOps ニュースレター購読

Thank you for signing up