Git フィーチャーブランチワークフロー

これによって main に基づいて new-feature というブランチがチェック アウトされて、ブランチがまだ存在していない場合は -b フラグによって作成されます。

このコマンドを実行すると、new-feature が中央リポジトリ (origin) にプッシュされて、-u フラグで new-feature がリモート追跡ブランチとして追加されます。追跡ブランチを設定すると、パラメーターを指定しなくても git push が呼び出されて、new-feature ブランチを中央リポジトリに自動でプッシュします。新しいフィーチャー ブランチのフィードバックを得るには、Bitbucket Cloud や Bitbucket Data Center などのリポジトリ管理ソリューションでプル リクエストを作成します。そこからレビュアーを追加して、マージの前に問題がないことを確認できます。

マージの前に、他の人がリポジトリに変更を加えた場合はマージの競合を解決する必要がある可能性があります。プル リクエストが承認されて競合がなくなったら、コードを main ブランチに追加できます。Bitbucket でプル リクエストからマージします。

ブランチは独立したフィーチャー開発を可能にしますが、加えてプル リクエストを利用して変更内容に関する議論を行えます。ある開発者がフィーチャー開発作業を完了したとしても、それを直ちに main にマージすることは避けるべきです。その代わりに、フィーチャー ブランチを中央サーバーにプッシュして他の開発者に対して変更内容を main にマージするように要請するプル リクエストを送信します。これによって、他の開発者は変更が main のコードベースに反映される前にその内容をレビューできるようになります。

コードレビューができることはプルリクエストの最大の利点ですが、そもそもプルリクエストはコードに関する議論を広く行う一般的な手法として設計されています。従ってプルリクエストは、そのブランチを対象として広く議論する手段であると考えても構いません。このことは、プルリクエストを開発プロセスの初期段階から活用できることを意味します。例えば、開発者があるフィーチャーに関して何か助言が欲しくなった場合にもプルリクエストを送ることが効果的です。通知は自動的に届くため、関心のある者は問題としているコミットの次に書かれている質問事項を読むと期待されます。

プル リクエストが承認されると、そのフィーチャーを公開する実際の操作は中央管理型ワークフローの場合とまったく同じです。最初に、ローカル main が上流の main に同期されていることを確認する必要があります。次にフィーチャー ブランチを main にマージして、更新された main を中央リポジトリにプッシュして戻します。

プルリクエストは、Bitbucket Cloud や Bitbucket Server のような製品リポジトリ管理ソリューションで利用できます。Bitbucket Server のプルリクエストドキュメントでその例をご覧ください。

フィーチャー開発の開始に当たって、Mary は作業を行うための独立したブランチを作成する必要があります。次のコマンドを実行して新しいブランチを作成します:

これは main を基点とする marys-feature という名称のブランチをチェック アウトするコマンドで、-b フラグを指定することによってそのブランチがまだ存在しない場合は作成するように指示しています。このブランチでは、Mary はいつもどおり同様に変更の編集、ステージ、コミットして、必要な数のコミットを実行して開発を進めます。

Mary は午前中にフィーチャーブランチにいくつかのコミットを行いました。昼食休憩をとる前に、フィーチャーブランチを中央リポジトリにプッシュしておくことは良い習慣です。これは簡便なバックアップの役割を果たしますが、コラボレーションを行っている場合は他の開発者が現段階のブランチにアクセスできるという利点もあります。

これは、marys-feature を中央リポジトリ (origin) にプッシュするコマンドで、-u フラグによりそれをリモート追跡ブランチに指定します。一度追跡ブランチの設定を行うと、パラメーターなしで git push を実行するだけでフィーチャーのプッシュを行えます。

Mary は昼食を終えた後、フィーチャー開発作業を完了しました。それを main にマージする前に、プル リクエストを送って他の開発者に作業が終わったことを知らせなければなりません。ただし、最初にプッシュしていないコミットをプッシュして中央リポジトリに反映します。

次に、Git GUI を使用して marys-feature の main へのマージを要請するプル リクエストを送ると、他の開発者に自動で通知が届きます。プル リクエストの優れている点は、関連するコミットの隣にコメントを表示できるため特定の変更内容に関して質問をすることが容易なことです。

Bill がプル リクエストを受け取り、marys-feature の内容を確認します。その結果、それを公式リポジトリに統合する前にいくつかの修正が必要であると判断し、Bill と Mary はプル リクエスト経由で何度か意見のやり取りを行いました。

Mary は、フィーチャーを最初に開発したときと全く同じ操作で修正を行います。即ち、編集、ステージ、コミットを行ない、最後に更新内容を中央リポジトリにプッシュします。すべての修正内容はプルリクエストに表示され、Bill は逐次コメントすることができます。

Bill は、必要な場合は marys-feature をローカル リポジトリにプルして自ら作業することも可能です。Bill が行ったコミットもすべてプル リクエストに表示されます。

Bill がプルリクエストを承認可能と判断した場合、誰か (Bill または Mary のいずれかで構いません) がフィーチャーを中央リポジトリにマージします:

以上の操作を実行すると、マージ コミットが生成される場合があります。マージ コミットはそれ以外のコード ベースとフィーチャーとのシンボリック結合と考えられるため、この方法を好む開発者もいます。ただし、直線的な履歴が好ましい場合は、マージを実行する前にフィーチャーを main の先端にリベースできて、これによってマージ処理は早送りマージとなります。

GUI によっては「承認」ボタンをクリックするだけでこれらすべてのコマンドを実行するという方法で、プル リクエストの承認プロセスを自動化したものもあります。自動化機能がない場合でも、少なくともフィーチャー ブランチの main へのマージが行われた時点でプル リクエストを自動で処理済みにできます。

この間に John も作業を進行させていました

Mary と Bill が marys-feature での作業とプルリクエストを経由した議論を行っている間に、John も自分のフィーチャーブランチ上で同様の作業を進行させていました。フィーチャーに個別にブランチを割り当てて独立させることにより、すべての開発者は独立した作業が可能でありながら、必要な場合に他の開発者と変更内容を共有することも簡単です。

このドキュメントでは、Git フィーチャー・ブランチ・ワークフローについて説明しました。ここのワークフローを使うとビジネス・ドメインのフィーチャー・セットに特化したブランチの整理と追跡を行えます。Git フォーク型ワークフローや Gitflow ワークフローのようなその他の Git ワークフローはリポジトリに特化していて、Git フィーチャー・ブランチ・ワークフローを活用して分岐モデルを管理できます。このドキュメントでは一般的なコード・サンプルとデモ用に作成したサンプルを実際に使って Git フィーチャー・ブランチ・ワークフローを実装しました。フィーチャー・ブランチ・ワークフローの主な特徴は以下のとおりです。

• 分岐パターンに特化している
• リポジトリ指向の他のワークフローにも活用できる
• プル リクエストとマージ レビューを使ってチーム メンバーとともにコラボレーションを推進できる

フィーチャー ブランチのレビューとマージのステージで git rebase を利用すると、フィーチャー マージの Git 履歴の密度を高められます。フィーチャー ブランチング モデルはチーム環境でコラボレーションを推進するのに最適なツールです。

Gitflow ワークフロー の包括的なチュートリアルを読めば、Git ワークフローをさらに深く理解できます。