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

フィーチャー ブランチ ワークフローの基本となる考えは、すべての機能開発は master ブランチではなく専用のブランチで行われるべきであるということです。このカプセル化により、複数の開発者がメインのコードベースを妨げることなく特定の機能に取り組みやすくなります。また、master ブランチに壊れたコードが含まれることはありません。これは継続的インテグレーション環境には大きなメリットです。

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

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

仕組み


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

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

master ブランチから始める

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

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

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

new-branch を作成する

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

git checkout -b new-feature

これによって master に基づいて 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 CloudBitbucket Server などのリポジトリ管理ソリューションでプル リクエストを作成します。そこからレビュアーを追加してマージの前に問題がないことを確認できます。

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

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

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

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

プルリクエスト

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

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

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

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

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

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

フィーチャーブランチワークフロー: 変更をコミットする

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

git checkout -b marys-feature master

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

git status
git add <some-file>
git commit

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

フィーチャーブランチワークフロー: git push

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

git push -u origin marys-feature

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

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

フィーチャーブランチワークフロー: git push

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

Git のプッシュ

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

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

フィーチャーブランチワークフロー: プルリクエストを確認する

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

Mary が修正を行います。

フィーチャーブランチワークフロー: プルリクエストの改訂

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

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

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

フィーチャーブランチワークフロー: フィーチャーブランチをマージする

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

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

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

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

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

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

概要


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

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

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

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

Git を学習する準備はできていますか?

この対話式チュートリアルを利用しましょう。

今すぐ始める