Gitflowワークフロー
Gitflowワークフローでは、機能ブランチワークフローで必要とされるものを除けば目新しいコンセプトはありません。その代わりに、さまざまなブランチに非常に特定されたロールを割り当てて、対話の方法と時期を定義します。
Gitflowワークフローも全開発者の通信ハブとして中央リポジトリーを使用します。そして機能ブランチワークフローと同じく、開発者はローカルに作業し、ブランチを中央リポジトリーにプッシュします。唯一の違いはプロジェクトのブランチ構造にあります。
プロジェクト履歴を記録するため、このワークフローは1つしかないmainブランチの代わりに2つのブランチを使います。mainブランチは公式のリリース履歴を保管し、developブランチは機能の統合ブランチとして使われます。mainブランチのコミットはすべてバージョン番号でタグ付けされます。
Gitflowワークフローが使われる時のシナリオタイプ例は次のとおりです。
![Gitflowワークフローの例。](/ja-JP/studio-user-guide/8.0-R2024-05/Content/Resources/images/studio-git-gitflow-workflow.png)
開発者であるAndyとLucyにそれぞれ、feature-123とfeature-456という新しい機能での作業が割り当てられたとします。
管理者はmainに基づいたdevelopブランチを作成し、Talend StudioでこのブランチをリモートGitリポジトリーにプッシュしました。
![mainブランチに基づいてdevelopブランチを作成し、リモートGitリポジトリーにプッシュ。](/ja-JP/studio-user-guide/8.0-R2024-05/Content/Resources/images/studio_gitflow_create_develop_branch.png)
AndyはTalend Studioでdevelopブランチに基づいた新しいブランチandy-feature-123を作成した後、新しく作成されたこのブランチに切り替えました。
![developブランチに基づいて新しいブランチを作成し、その新しいブランチに切り替え。](/ja-JP/studio-user-guide/8.0-R2024-05/Content/Resources/images/studio_gitflow_create_branch_in_studio.png)
Andyと同じく、LucyもTalend Studioでdevelopブランチに基づいた新しいブランチlucy-feature-123を作成した後、新しく作成されたこのブランチに切り替えました。
現在、AndyとLucyは新しい機能の作業をしており、自分のローカル機能ブランチでジョブをそれぞれ作成し、変更をリモートリポジトリーにプッシュします。
![変更をリモートリポジトリーにプッシュ。](/ja-JP/studio-user-guide/8.0-R2024-05/Content/Resources/images/studio_gitflow_create_job_and_push_branch_andy.png)
Andyはまだ自分の機能で作業していますが、Lucyは自分の機能の作業が終わり、リリースの準備を始めました。
Lucyはリモートブランチdevelopをローカルブランチとしてチェックアウトした後、ローカルブランチdevelopに切り替えました。
![リモートのdevelopブランチをローカルブランチとしてチェックアウトし、ローカルのdevelopブランチに切り替え。](/ja-JP/studio-user-guide/8.0-R2024-05/Content/Resources/images/studio_gitflow_check_out_as_local_branch.png)
次にLucyは、[Git Pull and Merge]ツールを使ってジョブを機能ブランチlucy-feature-456からローカルブランチdevelopにマージしました。
![Gitのプル&マージツールを使って、featureブランチのジョブをローカルブランチにマージ。](/ja-JP/studio-user-guide/8.0-R2024-05/Content/Resources/images/studio_gitflow_pull_and_merge_branch.png)
彼女はその後、ローカルブランチdevelopからリモートブランチdevelopに変更をプッシュしました。
![ローカルブランチでの変更をリモートブランチにプッシュ。](/ja-JP/studio-user-guide/8.0-R2024-05/Content/Resources/images/studio_gitflow_push_and_confirm.png)
管理者は、アップデートされたdevelopブランチから新しいreleaseブランチを作成し、リモートリポジトリーにそれをプッシュしました。Lucyはリリースを完了させました。
これで彼女は、必要がなくなったローカルブランチを削除できます。
![ローカルブランチを削除。](/ja-JP/studio-user-guide/8.0-R2024-05/Content/Resources/images/studio_gitflow_delete_local_branch.png)
出荷できるようになったので、Lucyはmainブランチをローカルブランチとしてチェックアウトし、[Git Pull and Merge]ツールを使ってリモートブランチreleaseからローカルブランチmainに変更をマージして、最後に変更をリモートブランチmainにプッシュしました。
Lucyはリモートブランチであるmainに切り替え、このブランチにリリースバージョンとタグ付けました。
また、releaseブランチはdevelopブランチにマージバックされる必要があります。このマージバックはリリースが開始してからすでに実行してきた場合があります。
![タグをブランチに追加。](/ja-JP/studio-user-guide/8.0-R2024-05/Content/Resources/images/studio_gitflow_add_tag_on_master.png)
現在のバージョンをリリースした後は、リリースされたそのバージョンを再調整する必要が生じるまで、開発者は次のリリースに向けた機能の開発に戻ることができます。
リリースされたバージョンで再び作業できるよう、開発者はリモートブランチmainをローカルブランチmaintenanceとしてチェックアウトし、問題を修正して変更をリモートリポジトリーにプッシュします。これによってリモートブランチmaintenanceが作成されます。
次に開発者はリモートブランチmainをローカルブランチとしてチェックアウトし、リモートブランチmaintenanceからプルしてマージするリクエストを実行して、ローカルブランチmainからリモートブランチmainにプッシュします。これで、maintenanceブランチでのバグ修正に関する変更がリモートブランチmainにマージされました。
次に、開発者はリモートブランチmainをv1.0.1というホットフィックスのナンバリングでタグ付けします。
リリースブランチのようにメンテナンスブランチもdevelopブランチでマージされる必要があるため、開発者はそのマージを実行すると同時に、必要でないローカルブランチを削除しなければなりません。