Git機能ブランチワークフロー
Git機能ブランチワークフローは、Talend Studioでチーム作業するうえで効率的です。このワークフローでは、mainブランチとは別の専用ブランチで機能開発がすべて行われます。
機能ブランチワークフローは中央リポジトリーを前提としています。mainは公式のプロジェクト履歴を表します。新しい機能の作業を開始するたびに、開発者はローカルmainブランチで直接コミットする代わりに新しいブランチを作成します。したがって、mainブランチに触れることなく、複数の開発者が1つまたは複数の機能で同時に作業できます。
以下は、機能ブランチワークフローが使われたシナリオタイプ例です。これは、このモデルを利用できる数多い目的の一例です。
あるチームで、2人の開発者(AndyとLucy)が同じtalend-123という機能で作業しているとします。
最初に、Andyにこの新しい機能の作業が割り当てられました。彼は、Talend Studioでmainに基づいて新しい機能ブランチtalend-123を作成しました。
Andyは今、Talend Studioでtalend-123というGitローカルブランチにログインしました。この時点で、このブランチはAndyのマシンにのみ存在しています。
リモートGitリポジトリーで機能ブランチが作成できるよう、AndyはTalend Studioで提供されているGitプッシュツールでプッシュを実行しました。
Andyはjob1とjob2という2つのジョブを作成しました。この変更は、保存時にローカルブランチに自動でコミットされます。次に彼は、Talend Studioで提供されているGitプッシュツールを使い、変更をリモートGitブランチに手動でプッシュしました。
ここで、Lucyにもこの機能の作業が割り当てられました。彼女はリモート機能ブランチであるtalend-123をローカルブランチとしてチェックアウトした後、このローカルブランチでジョブjob1を変更し、新しいジョブjob3を作成しました。
Lucyがジョブjob1で作業している間、Andyもジョブjob1で変更を行い、ローカル機能ブランチでジョブレットjoblet1を作成してリモートリポジトリーに変更をプッシュしました。
Lucyは自分のジョブであるjob1とjob3の変更をリモートブランチtalend-123にプッシュしようとしましたが、Andyもジョブjob1の変更をリモートリポジトリーにプッシュしたばかりだったため、Lucyのプッシュはリジェクトされました。
Lucyはまずリモート機能ブランチであるtalend-123からプルする必要がありますが、AndyもLucyもジョブjob1で変更を行ったため競合が見つかりました。
Lucyはこの競合を解決しなければなりません。このケースでは、LucyはAndyの変更をすべて受け入れ、競合を解決済みとしてマークしました。競合がすべて解決されると、プルが完了します。Lucyは自分の変更を正しくプッシュしました。
ブランチ間の競合を解決する詳細については、 ブランチ間の競合を解決をご覧ください。
talend-123というリモート機能ブランチには現在、両開発者の変更が含まれています。
機能の開発が終わったら、開発者はリモート機能ブランチtalend-123での変更をリモートブランチmainにマージします。このマージは、リモートブランチmainをローカルブランチとしてチェックアウトし、リモートブランチtalend-123からプルしてマージするリクエストを実行し、ローカルブランチmainからリモートブランチmainにプッシュすることで行われます。
