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

フィーチャーブランチワークフローの基本となる考えは、すべての機能開発を main ブランチではなく専用のブランチで行う必要があるということです。このカプセル化によって、main のコードベースに影響を与えることなく複数の開発者が別々のフィーチャー開発作業を行えるようになります。また、main ブランチに壊れたコードは含まれません。これは、継続的なインテグレーション環境にとって大きなメリットになります。

専用ブランチによるフィーチャー開発のカプセル化は、そのブランチに関連した問題点の議論の開始方法としてのプルリクエストの活用を可能にします。プルリクエストとは、フィーチャーを中央リポジトリに統合する前に他の開発者に承認してもらうための手段です。あるいはフィーチャー開発中に行き詰まった場合に、プルリクエストを送ることにより他の開発者からの助言を求めることもできます。つまり、プルリクエストは作業内容に関してチーム内で相互にコメントし合うための非常に簡便な仕組みだという点です。

Git フィーチャーブランチワークフローは構成可能なワークフローで、他の一般的な Git ワークフローで活用できます。Git ワークフローの概要ページで取り上げています。Git フィーチャーブランチワークフローは分岐モデルに特化しています。つまり、ブランチの管理と作成をガイドするためのフレームワークであります。他のワークフローはどちらかというとリポジトリに特化しています。Git フィーチャーブランチワークフローは、他のワークフローに組み込めます。Gitflow と Git フォーク型ワークフローは従来、分岐モデルに関しては Git フィーチャーブランチワークフローを使っています。

仕組み

フィーチャーブランチワークフローでは中央リポジトリがあると仮定しており、main は公式のプロジェクト履歴を表しています。ローカルの main ブランチに直接コミットする代わりに、開発者は新しいフィーチャーに取り組むたびに新しいブランチを作成します。animated-menu-items や issue-#1061 など、フィーチャーブランチにはわかりやすい名前を付ける必要があります。これは、各ブランチの目的をわかりやすく絞り込むためです。Git では main ブランチとフィーチャーブランチを技術的な観点から区別しないので、開発者はフィーチャーブランチで変更を編集、ステージ、コミットできます。

加えて、フィーチャーブランチは中央リポジトリにプッシュでき、また実際にプッシュします。これによって、公式のコードに変更を加えずにフィーチャーを他の開発者と共有できます。main ブランチのみが「特別な」ブランチであり、中央リポジトリにフィーチャーブランチをいくつ保存しても問題は引き起こされません。当然、これは各人のローカルなコミットをバックアップする便利な方法でもあります。次は、フィーチャーブランチのライフサイクルを実際に見ていきましょう。

main ブランチから開始する

すべてのフィーチャーブランチは、プロジェクトの最新のコード状態とは離れて作成されます。このガイドではその状態が維持されており main ブランチで更新されていると仮定します。

git checkout main
git fetch origin 
git reset --hard origin/main

これによってリポジトリを main ブランチに切り替えて最新のコミットをプルし、最新バージョンと一致するようにリポジトリにある main のローカルコピーをリセットします。

new-branch を作成する

各フィーチャーまたは作業中の課題で別々のブランチを使います。ブランチを作成したら、ローカルでチェックアウトして、加えたすべての変更がそのブランチに含まれるようにします。

git checkout -b new-feature

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

変更の更新、追加、コミット、プッシュ

このブランチでは通常の方法で変更の編集、ステージ、コミットを行って、必要な数のコミットを使ってフィーチャーを構築します。フィーチャーで作業を行い、いつも Git を使っている時と同じようにコミットを作成します。準備ができたらコミットをプッシュして Bitbucket のフィーチャーブランチを更新します。

git status
git add <some-file>
git commit

フィーチャーブランチをリモートにプッシュする

フィーチャーブランチを中央リポジトリまでプッシュしておいたほうが良いでしょう。これは便利なバックアップとなり、共同作業している他の開発者がアクセスして新しいブランチへのコミットを見ることができます。

git push -u origin new-feature

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

フィードバックを解決する

これでチームメイトがコメントを入力して、プッシュされたコミットを承認できるようになりました。ローカルでこれらのコメントを解決して提案された変更を Bitbucket にコミットしてプッシュします。更新した内容はプルリクエストに表示されます。

プルリクエストをマージする

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

プルリクエスト

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

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

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

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

例

以下はフィーチャーブランチワークフローを使うシナリオタイプのサンプルです。こちらは、新しいフィーチャーのプルリクエストでコードレビューを行っているチームのシナリオになっています。このサンプルはこのモデルを適用できるさまざまな用途の一例です。

Mary が新たなフィーチャー開発作業を開始します。

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

 git checkout -b marys-feature main

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

git status
git add <some-file>
git commit

Mary が昼食休憩を取ります。

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

git push -u origin marys-feature

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

Mary がフィーチャーを公開します。

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

Git のプッシュ

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

Bill がプルリクエストを受け取ります。

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

Mary が修正を行います。

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

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

Mary がフィーチャーを公開します。

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

git checkout main
git pull
git pull origin marys-feature
git push

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

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

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

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

概要

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