Close

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

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

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

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


仕組み


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

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

main ブランチから開始する

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

コンソール・ウィンドウ
関連資料

高度な Git ログ

Bitbucket ロゴ
ソリューションを見る

Bitbucket Cloud での Git の使用方法についてのチュートリアルです。

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

ステップ 1. リポジトリの作成

これによってリポジトリを 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 CloudBitbucket 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 push

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

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 フィーチャー・ブランチ・ワークフローを実装しました。フィーチャー・ブランチ・ワークフローの主な特徴は以下のとおりです。

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

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

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


この記事を共有する
次のトピック

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

一面のツールを使ってコラボレーションしている人たち

Bitbucket ブログ

DevOps のイラスト

DevOps ラーニング パス

Demo Den アトラシアン・エキスパートによる機能デモ

Bitbucket Cloud が、Atlassian Open DevOps とどのように連携するか

DevOps ニュースレター購読

Thank you for signing up