Gitflow ワークフロー
Gitflow とは、元来は Git ブランチを管理するための破壊的で斬新な戦略のレガシー Git ワークフローです。Gitflow の需要は落ち込み、トランク ベースのワークフローが利用されるようになっています。現在ではこれが最新の継続的なソフトウェア開発のベスト プラクティスおよび DevOps プラクティスと見なされています。Gitflow はまた、CI/CD と使用することも困難な場合があります。この投稿では、歴史的な目的で Gitflow の詳細をご説明します。
Gitflow とは?
Gitflow とは、フィーチャー ブランチと複数のプライマリ ブランチを使用する代替 Git ブランチ モデルです。nvie の Vincent Driessen 氏が初めて公開して有名になりました。トランク ベース開発と比較して、Gitflow には永続的なブランチと大規模なコミットがあります。このモデルでは、開発者はフィーチャー ブランチを作成して、フィーチャーが完成するまでメインのトランク ブランチへのマージを延期します。これらの永続的なフィーチャー ブランチでは、マージにはより多くのコラボレーションが必要となり、トランク ブランチから逸脱するリスクが高くなります。また、アップデートの競合の原因にもなります。
Gitflow は、リリース サイクルがあらかじめ決まっているプロジェクトと継続的なデリバリーを提供する DevOps ベスト プラクティスに利用できます。このワークフローでは、フィーチャー ブランチ ワークフローに使用されているもの以外の概念や命令は不要です。その代わり、異なるブランチに対して個別にロールを割り当て、それらが相互に作用する手順や条件を定義します。また、フィーチャー ブランチに加え、リリースの準備、保守、記録を行うためにそれぞれのブランチを使用します。言うまでもなくプル リクエストや隔離実験等のフィーチャー ブランチ ワークフローのすべての特長を利用でき、コラボレーションのさらなる効率化が実現できます。
関連資料
高度な Git ログ
ソリューションを見る
Bitbucket Cloud での Git の使用方法についてのチュートリアルです。
仕組み
develop ブランチと main ブランチ
このワークフローでは 1 つの main ブランチだけではなく、プロジェクトの履歴を記録するために 2 つのブランチを使用します。main ブランチは公式のリリース履歴を保管して、develop ブランチはフィーチャーの組み込みブランチとして機能します。また、main ブランチにすべてのコミットをバージョン番号つきでタグ付けするのが便利です。
最初のステップは、デフォルトの main に対して develop ブランチを作成することです。これを行う簡単な方法は、1 人の開発者が空白の develop ブランチをローカルに作成してサーバーに送ることです。
git branch develop
git push -u origin developmain には要約版が保管されるのに対して、このブランチにはプロジェクトの全履歴が保管されます。この時点で、他の開発者はセントラル リポジトリを複製して開発用のトラッキング ブランチを作成する必要があります。
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 と直接作用してはいけないことにご注意ください。
なお、feature ブランチおよび develop ブランチの組み合わせは、まさにフィーチャー ブランチ ワークフローそのものです。しかしながら、Gitflow ワークフローには他にも多くの機能があります。
feature ブランチは通常、最新の develop ブランチに関連付けられます。
フィーチャーブランチの作成
git-flow エクステンションなし:
git checkout develop
git checkout -b feature_branchgit-flow エクステンションあり:
git flow feature start feature_branch作業を続行していつも通り Git を使ってください。
フィーチャーブランチの仕上げ
フィーチャーの開発作業が完了したら、次は feature_branch を develop にマージします。
git-flow エクステンションなし:
git checkout develop
git merge feature_branchgit-flow エクステンションあり:
git flow feature finish feature_branchリリース ブランチ
develop においてフィーチャーがリリース可能であると確認できた (あるいはリリース予定期日が近くなった) 場合は、develop から release ブランチを分岐させます。このブランチを作成すると新たなリリース サイクルが開始されるため、この時点からは新規フィーチャーを追加できません。このブランチにおいては、バグ修正、ドキュメント生成、その他のリリースに伴うタスクのみを実行できます。リリースの準備が整うと、release ブランチは main にマージされてバージョン番号でタグ付けされます。さらに、リリース作成以降の進捗が反映された develop にマージして戻す必要があります。
このようなリリース専用ブランチを利用することにより、あるチームでは進行中のリリース準備を行いつつ他のチームでは次のリリースに向けたフィーチャー開発を同時に行うことが可能となります。またこの機能により開発のフェーズをより明確にできます (たとえば、「今週はバージョン 4.0 の作業をする」と明確に定義できると同時に、それがリポジトリの実際の構造に反映されます)。
シンプルなブランチング操作としては release ブランチの作成もあります。feature ブランチ同様、release ブランチも develop ブランチをベースにしています。新規の release ブランチを作成する方法は以下のとおりです。
git-flow エクステンションなし:
git checkout develop
git checkout -b release/0.1.0git-flow エクステンションあり:
$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'リリースの準備が整うと、main と develop にマージして release ブランチを削除します。ここで develop ブランチにマージして戻すことが重要です。これは release ブランチには重要な更新が加えられている可能性があり、新機能に開発者がアクセスできるようにするためです。所属組織がコード レビューを重視している場合は、この時点でプル リクエストを送ります。
以下の方法で release ブランチを仕上げます。
git-flow エクステンションなし:
git checkout main
git merge release/0.1.0git-flow エクステンションあり:
git flow release finish '0.1.0'hotfix ブランチ
「Hotfix」 ブランチとも呼ばれるメンテナンスは、本番リリースに対して迅速にパッチを当てて修正する場合に使用します。Hotfix ブランチは develop ではなく main をベースにしている点を除いて、release ブランチと feature ブランチによく似ています。hotfix ブランチは main から直接分岐する唯一のブランチです。修正が完了すると main と develop の両方に (あるいは進行中の release ブランチに) 直ちにマージされて、main は更新されたバージョン番号でタグ付けされます。
バグ修正専用の開発ラインを備えることによって、チームはワークフローの他の部分と干渉することなく問題に対応できて、次のリリース サイクルを待つ必要もなくなります。メンテナンス ブランチは、main と直接作用する一時的な release ブランチとして捉えられます。hotfix ブランチは次の方法で作成できます。
git-flow エクステンションなし:
git checkout main
git checkout -b hotfix_branchgit-flow エクステンションあり:
$ git flow hotfix start hotfix_branchrelease ブランチの仕上げと同じように、hotfix ブランチは main と develop の両方にマージされます。
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_branchfeature フローと 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 ブランチが完成すると、develop と main にマージされます
6.main に問題が検出されると、hotfix ブランチが main から作成されます
7. hotfix が完了すると、develop と main の両方にマージされます
次はフォーク型ワークフローについて確認するか、ワークフロー比較ページに進んでください。
この記事を共有する
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。
Bitbucket ブログ
DevOps ラーニング パス
