Gitflowワークフロー

Gitflowワークフローでは、機能ブランチワークフローで必要とされるものを除けば目新しいコンセプトはありません。その代わりに、さまざまなブランチに非常に特定されたロールを割り当てて、対話の方法と時期を定義します。

Gitflowワークフローも全開発者の通信ハブとして中央リポジトリーを使用します。そして機能ブランチワークフローと同じく、開発者はローカルに作業し、ブランチを中央リポジトリーにプッシュします。唯一の違いはプロジェクトのブランチ構造にあります。

プロジェクト履歴を記録するため、このワークフローは1つしかないmainブランチの代わりに2つのブランチを使います。mainブランチは公式のリリース履歴を保管し、developブランチは機能の統合ブランチとして使われます。mainブランチのコミットはすべてバージョン番号でタグ付けされます。

Gitflowワークフローが使われる時のシナリオタイプ例は次のとおりです。

開発者であるAndyとLucyにそれぞれ、feature-123とfeature-456という新しい機能での作業が割り当てられたとします。

管理者はmainに基づいたdevelopブランチを作成し、Talend StudioでこのブランチをリモートGitリポジトリーにプッシュしました。

AndyはTalend Studioでdevelopブランチに基づいた新しいブランチandy-feature-123を作成した後、新しく作成されたこのブランチに切り替えました。

Andyと同じく、LucyもTalend Studioでdevelopブランチに基づいた新しいブランチlucy-feature-123を作成した後、新しく作成されたこのブランチに切り替えました。

現在、AndyとLucyは新しい機能の作業をしており、自分のローカル機能ブランチでジョブをそれぞれ作成し、変更をリモートリポジトリーにプッシュします。

Lucyはまだ自分の機能で作業していますが、Andyは自分の機能の作業が終わり、リリースの準備を始めました。

Andyはリモートブランチdevelopをローカルブランチとしてチェックアウトした後、ローカルブランチdevelopに切り替えました。

次にAndyは、[Git Pull and Merge]ツールを使ってジョブを機能ブランチandy-feature-123からローカルブランチdevelopにマージしました。彼はその後、ローカルブランチdevelopからリモートブランチdevelopに変更をプッシュしました。

管理者は、アップデートされたdevelopブランチから新しいreleaseブランチを作成し、リモートリポジトリーにそれをプッシュしました。Andyはリリースを完了させました。

これで彼は、必要がなくなったローカルブランチを削除できます。

出荷できるようになったので、Andyはmainブランチをローカルブランチとしてチェックアウトし、[Git Pull and Merge]ツールを使ってリモートブランチreleaseからローカルブランチmainに変更をマージして、最後に変更をリモートブランチmainにプッシュしました。

Andyは、リモートブランチであるmainにリモートバージョンをタグ付けしました。

また、releaseブランチはdevelopブランチにマージバックされる必要があります。このマージバックはリリースが開始してからすでに実行してきた場合があります。

現在のバージョンをリリースした後は、リリースされたそのバージョンを再調整する必要が生じるまで、開発者は次のリリースに向けた機能の開発に戻ることができます。

リリースされたバージョンで再び作業できるよう、開発者はリモートブランチmainをローカルブランチmaintenanceとしてチェックアウトし、問題を修正して変更をリモートリポジトリーにプッシュします。これによってリモートブランチmaintenanceが作成されます。

次に開発者はリモートブランチmainをローカルブランチとしてチェックアウトし、リモートブランチmaintenanceからプルしてマージするリクエストを実行して、ローカルブランチmainからリモートブランチmainにプッシュします。これで、maintenanceブランチでのバグ修正に関する変更がリモートブランチmainにマージされました。

次に、開発者はリモートブランチmainをv1.0.1というホットフィックスのナンバリングでタグ付けします。

リリースブランチのようにメンテナンスブランチもdevelopブランチでマージされる必要があるため、開発者はそのマージを実行すると同時に、必要でないローカルブランチを削除しなければなりません。