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は新しい機能の作業をしており、自分のローカル機能ブランチでジョブをそれぞれ作成し、変更をリモートリポジトリーにプッシュします。
Andyはまだ自分の機能で作業していますが、Lucyは自分の機能の作業が終わり、リリースの準備を始めました。
Lucyはリモートブランチdevelopをローカルブランチとしてチェックアウトした後、ローカルブランチdevelopに切り替えました。
次にLucyは、[Git Pull and Merge]ツールを使ってジョブを機能ブランチlucy-feature-456からローカルブランチdevelopにマージしました。
彼女はその後、ローカルブランチdevelopからリモートブランチdevelopに変更をプッシュしました。
管理者は、アップデートされたdevelopブランチから新しいreleaseブランチを作成し、リモートリポジトリーにそれをプッシュしました。Lucyはリリースを完了させました。
これで彼女は、必要がなくなったローカルブランチを削除できます。
出荷できるようになったので、Lucyはmainブランチをローカルブランチとしてチェックアウトし、[Git Pull and Merge]ツールを使ってリモートブランチreleaseからローカルブランチmainに変更をマージして、最後に変更をリモートブランチmainにプッシュしました。
Lucyはリモートブランチであるmainに切り替え、このブランチにリリースバージョンとタグ付けました。
また、releaseブランチはdevelopブランチにマージバックされる必要があります。このマージバックはリリースが開始してからすでに実行してきた場合があります。
現在のバージョンをリリースした後は、リリースされたそのバージョンを再調整する必要が生じるまで、開発者は次のリリースに向けた機能の開発に戻ることができます。
リリースされたバージョンで再び作業できるよう、開発者はリモートブランチmainをローカルブランチmaintenanceとしてチェックアウトし、問題を修正して変更をリモートリポジトリーにプッシュします。これによってリモートブランチmaintenanceが作成されます。
次に開発者はリモートブランチmainをローカルブランチとしてチェックアウトし、リモートブランチmaintenanceからプルしてマージするリクエストを実行して、ローカルブランチmainからリモートブランチmainにプッシュします。これで、maintenanceブランチでのバグ修正に関する変更がリモートブランチmainにマージされました。
次に、開発者はリモートブランチmainをv1.0.1というホットフィックスのナンバリングでタグ付けします。
リリースブランチのようにメンテナンスブランチもdevelopブランチでマージされる必要があるため、開発者はそのマージを実行すると同時に、必要でないローカルブランチを削除しなければなりません。