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

フィーチャーブランチワークフローの核となる概念は、すべてのフィーチャー開発を、ブランチではなく専用のブランチ上で行うことにあります。このカプセル化により、master ブランチに影響を与えることなく複数の開発者が別々のフィーチャー開発作業を行うことが可能になります。また、この手法によって master ブランチに不良コードが入ることがなくなり、コードの継続的インテグレーション統合環境においては大きな利点となります。

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

Git フィーチャーブランチワークフローは構成可能なワークフローで、他の一般的な 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  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  git commit

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

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

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

git push -u origin marys-feature

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

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

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

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

git push

次に、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 を学ぶ準備はできていますか?

この対話式のチュートリアルをお試しください。

今すぐ始める