# Gitflowワークフロー

Gitflowワークフローでは、プロジェクトリリースを中心にデザインされた厳密なブランチングモデルが定義されています。それによって、大型のプロジェクトでも管理できる堅牢なフラームワークの利用が可能です。

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

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

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

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

![Gitflowワークフローの例。](https://help.qlik.com/talend/ja-JP/studio-user-guide/Resources/images/studio-git-gitflow-workflow.png)

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

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

![mainブランチに基づいてdevelopブランチを作成し、リモートGitリポジトリーにプッシュ。](https://help.qlik.com/talend/ja-JP/studio-user-guide/Resources/images/studio_gitflow_create_develop_branch.png)

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

![developブランチに基づいて新しいブランチを作成し、その新しいブランチに切り替え。](https://help.qlik.com/talend/ja-JP/studio-user-guide/Resources/images/studio_gitflow_create_branch_in_studio.png)

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

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

![変更をリモートリポジトリーにプッシュ。](https://help.qlik.com/talend/ja-JP/studio-user-guide/Resources/images/studio_gitflow_create_job_and_push_branch_andy.png)

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

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

![リモートのdevelopブランチをローカルブランチとしてチェックアウトし、ローカルのdevelopブランチに切り替え。](https://help.qlik.com/talend/ja-JP/studio-user-guide/Resources/images/studio_gitflow_check_out_as_local_branch.png)

次にLucyは、[Git Pull and Merge]ツールを使ってジョブを機能ブランチlucy-feature-456からローカルブランチdevelopにマージしました。

![Gitのプル＆マージツールを使って、featureブランチのジョブをローカルブランチにマージ。](https://help.qlik.com/talend/ja-JP/studio-user-guide/Resources/images/studio_gitflow_pull_and_merge_branch.png)

彼女はその後、ローカルブランチdevelopからリモートブランチdevelopに変更をプッシュしました。

![ローカルブランチでの変更をリモートブランチにプッシュ。](https://help.qlik.com/talend/ja-JP/studio-user-guide/Resources/images/studio_gitflow_push_and_confirm.png)

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

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

![ローカルブランチを削除。](https://help.qlik.com/talend/ja-JP/studio-user-guide/Resources/images/studio_gitflow_delete_local_branch.png)

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

Lucyはリモートブランチであるmainに切り替え、このブランチにリリースバージョンとタグ付けました。

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

![タグをブランチに追加。](https://help.qlik.com/talend/ja-JP/studio-user-guide/Resources/images/studio_gitflow_add_tag_on_master.png)

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

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

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

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

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