プルリクエストを実行する
プル リクエストは、Bitbucket を使用して開発者のコラボレーションを促進する機能の 1 つです。使いやすいウェブ インターフェイスを備えており、提案された変更を公式プロジェクトに統合する前に議論できます。
掻い摘んで説明すると、プル リクエストは開発者がフィーチャー開発作業の完了をチーム メンバーに通知するメカニズムです。フィーチャー ブランチが準備できると、開発者は Bitbucket アカウントからプル リクエストを送信します。これによって、関係者全員がコードのレビューと main ブランチへのマージが必要であることを知らされます。
しかし、プルリクエストは単なる通知機能ではありません。提案されたフィーチャーを議論するための専用フォーラムです。変更に何か問題があれば、プルリクエストに対してチームメンバーがフィードバックを投稿し、追加コミットをプッシュすることでフィーチャーの微調整さえ可能です。このすべての内容をプルリクエストで直接トラッキングできます。
この正規のコミット共有ソリューションは、他のコラボレーションモデルと比べて非常に無駄のないワークフローです。SVN や Git でも、単純なスクリプトを使って通知メールを自動送信できます。しかし、変更の議論に関しては、開発者はメールスレッドに頼らざるを得ないことが多いです。これは、追加コミットが関わってくる場合などに、混乱したものにもなりえます。プルリクエストは、使いやすい Web インターフェイスで、この機能をすべて Bitbucket リポジトリのすぐ隣に表示します。
プルリクエストの構造
プル リクエストを送信する際に行うことは、他の開発者 (例: プロジェクト メンテナー) が自分のリポジトリから開発者のリポジトリへブランチをプルするようにリクエストすることだけです。つまり、プル リクエストを送信するには、マージ元リポジトリ、マージ元ブランチ、マージ先リポジトリ、マージ先ブランチの 4 つの情報を提供する必要があります。
これらの値の多くは、Bitbucket によって適切なデフォルト値に設定されます。しかし、利用しているコラボレーション ワークフローによっては、異なる値を指定する必要がある場合があります。上記の図は、あるフィーチャー ブランチの公式 main ブランチへのマージを要請するプル リクエストを表しています。しかし、プル リクエストを使用する方法は他にも数多くあります。
仕組み
プル リクエストは、フィーチャー ブランチ ワークフロー、Gitflow ワークフロー、またはフォーク型ワークフローと組み合わせて使用できます。ただし、プル リクエストには 2 つの個別のブランチまたは 2 つの個別のリポジトリが必要なため、集中化ワークフローでは機能しません。これらの各ワークフローでプル リクエストを使用する方法は少し異なりますが、一般的なプロセスは次のとおりです。
開発者は、ローカルリポジトリの専用ブランチにこのフィーチャーを作成します。
同開発者が、ブランチを Bitbucket 公開リポジトリにプッシュする。
同開発者が、Bitbucket でプルリクエストを送信する。
チームの残りのメンバーはコードをレビューし、話し合い、変更します。
プロジェクトメンテナーは、そのフィーチャーを公式リポジトリにマージし、プルリクエストをクローズします。
このセクションの残りの部分では、様々なコラボレーションワークフローに対してどのようにプルリクエストを活用できるかについて説明します。
フィーチャー ブランチ ワークフローでのプルリクエスト
フィーチャー ブランチ ワークフローでは Bitbucket 共有リポジトリを使用してコラボレーションを管理し、開発者は独立したブランチにフィーチャーを作成します。フィーチャーは main に直ちにマージされるのではなく、開発者はプル リクエストをオープンして、メインのコードベースへ統合する前にフィーチャーに関する議論を開始する必要があります。
フィーチャー ブランチ ワークフローでは公開リポジトリは 1 つだけなので、プル リクエストのマージ先リポジトリとマージ元リポジトリは常に同じになります。通常、開発者はフィーチャー ブランチをマージ元ブランチとして、main ブランチをマージ先ブランチとして指定します。
プル リクエストを受け取った後、プロジェクト管理者は対応を決定する必要があります。フィーチャーがマージできる状態であれば、main にマージしてプル リクエストのステータスを処理済みに変更するだけです。提案された変更に問題がある場合は、プル リクエストにフィードバックを投稿できます。その直後に、関連コメントのすぐ隣に追加コミットが表示されます。
未完成のフィーチャーのプルリクエストを送信することもできます。例えば、開発者が特定の機能の実装に行き詰まった時、作業中のフィーチャーのプルリクエストを送信できます。他の開発者はそのプルリクエストに助言を提供し、追加コミットで問題を修正することさえ可能です。
Gitflow ワークフローでのプルリクエスト
Gitflow ワークフローはフィーチャー ブランチ ワークフローに類似していますが、プロジェクトのリリースに関連した利用を想定して設計された厳密なブランチモデルを定義しています。Gitflow ワークフローにプルリクエストを追加すると、作業中の開発者にリリース ブランチやメンテナンス ブランチに関して議論する便利な場を提供できます。
Gitflow ワークフローでのプルリクエストの構造は、前項とまったく同じです。開発者は、フィーチャー/リリース/hotfix ブランチに対するレビューが必要な時にプルリクエストを送信するだけです。 他のチームメンバーには Bitbucket で通知が届きます。
一般的に、フィーチャーは develop ブランチに、リリース ブランチと hotfix ブランチは develop と main の両方にマージされます。これらすべてのマージを公式に管理するためにプル リクエストを使用できます。
フォーク型ワークフローでのプルリクエスト
フォーク型ワークフローでは、開発者は完了したフィーチャーを共有リポジトリではなく自分の公開リポジトリにプッシュします。その後、プル リクエストを送信して、レビューの準備ができたことをプロジェクト メンテナーに通知します。
プロジェクトメンテナーは、他の開発者それぞれが独自の Bitbucket リポジトリにコミットを追加したことを知る手段はないので、このワークフローでは、プルリクエストの通知機能が特に役立ちます。
各開発者は独自の公開リポジトリを持っているため、プル リクエストのマージ元リポジトリはマージ先リポジトリとは別のものになります。マージ元リポジトリは開発者の公開リポジトリ、マージ元ブランチは変更提案を含むブランチとなります。開発者がフィーチャーをメインのコードベースにマージしようとしている場合、マージ先リポジトリは公式プロジェクトとなってマージ先ブランチは main となります。
プル リクエストは、公式プロジェクト以外の他の開発者とのコラボレーションにも使用できます。たとえば、開発者がチーム メンバーと一緒にフィーチャーを作業する場合、公式プロジェクトの代わりにチーム メンバーの Bitbucket リポジトリをマージ先として使用してプル リクエストを送信できます。その場合、マージ元とマージ先のブランチに同じフィーチャー ブランチを使用します。
2 人の開発者は、プル リクエスト内でフィーチャーについて協議して開発できました。完了すると、そのうちの 1 人がそのフィーチャーを公式の main ブランチにマージするように求める別のプル リクエストを送信します。このような柔軟性によって、フォークするワークフローではプル リクエストが非常に強力なコラボレーション ツールになります。
例
以下の例は、フォークするワークフローでどのようにプルリクエストを使用できるかを示しています。これは、小規模なチームで作業する開発者やオープンソースプロジェクトに貢献しているサードパーティの開発者にも同様に適用できます。
この例では、Mary は開発者であり、John はプロジェクトメンテナーです。どちらも独自のパブリック Bitbucket リポジトリを持ち、John のリポジトリには公式プロジェクトが含まれています。
Mary が公式リポジトリをフォークします。
プロジェクトの作業を開始するには、まず Mary が John の Bitbucket リポジトリをフォークする必要があります。これを行うには、Bitbucket にサインインし、John のリポジトリに移動して、フォーク ボタンをクリックします。
フォークしたリポジトリに名前と説明を記入したら、Mary はサーバーサイドにこのプロジェクトのコピーを保有することになります。
Mary がフォークした Bitbucket リポジトリをクローンします
次に、Mary はフォークした Bitbucket リポジトリをクローンする必要があります。クローンにより、Mary はローカルマシンに作業用のプロジェクトのコピーを保有することになります。Mary が使用するコマンドは次のようになります。
git clone https://user@bitbucket.org/user/repo.gitgit clone は、Mary のフォークされたリポジトリを指す origin リモートを自動作成します。
Mary が新しいフィーチャーを作成します。
Mary はコードを書き始める前にまず、作業フィーチャー用に新しいブランチを作成する必要があります。このブランチは、Mary によってプルリクエストのマージ元ブランチとして使われることになります。
git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"Mary は、必要な数だけコミットを使用してフィーチャーを作成できます。また、フィーチャーの履歴が思ったよりも乱雑な場合は、インタラクティブ リベースを使用して不要なコミットを削除またはスカッシュできます。大規模プロジェクトでは、フィーチャーの履歴をクリーン アップすることで、プロジェクト メンテナーはプル リクエストで何が起こっているのかを簡単に確認できます。
Mary が自分の Bitbucket リポジトリにフィーチャーをプッシュします
フィーチャー開発が完了したら、Mary は git push を実行するだけで、フィーチャー ブランチを自分の Bitbucket リポジトリ (公式リポジトリとは別) にプッシュできます。
git push origin some-branchこれで、 プロジェクトメンテナー (または、変更を入手する必要がある他の協力者) は Mary の変更を見れるようになります 。
Mary がプルリクエストを作成します
Bitbucket で自分のフィーチャー ブランチが設定されると、Mary は Bitbucket アカウントからフォークされたリポジトリに移動し、右上隅にあるプル リクエスト ボタンをクリックすることで、プル リクエストを作成できます。結果のフォームは、Mary のリポジトリを自動的にマージ元として設定し、Mary はマージ元ブランチ、マージ先リポジトリ、マージ先ブランチを指定するように求められます。
Mary は自分のフィーチャーをメインのコードベースにマージしたいので、マージ元ブランチは Mary のフィーチャー ブランチ、マージ先リポジトリは John の公開リポジトリ、マージ先ブランチは main となります。また、Mary はプル リクエストに対してタイトルと説明を入力する必要があります。John 以外にコードを承認する必要がある人がいる場合は、Mary はそのユーザーをレビュアー フィールドに追加できます。
Mary がプルリクエストを作成した後、Bitbucket フィードを介して John に通知が送信されます (オプション)。
John はプルリクエストをレビューします。
John は、自分の Bitbucket リポジトリのプル リクエスト タブをクリックすると、送信されたすべてのプル リクエストにアクセスできます。Mary のプル リクエストをクリックすると、プル リクエストの説明、フィーチャーのコミット履歴、含まれているすべての変更の差分が表示されます。
Mary のフィーチャーはプロジェクトにマージできるものだと John が判断すれば、John はマージ ボタンをクリックするだけでプル リクエストを承認して、Mary のフィーチャーは John の main ブランチにマージされます。
しかし、例えば、John が Mary のコードに小さなバグを発見し、マージ前に Mary にそのバグを修正させる必要があるとします。この場合、John は、プルリクエスト全体に対してコメントを投稿するか、または、フィーチャー履歴の特定のコミットを選択してコメントを書く事ができます。
Mary はフォローアップコミットを追加します。
Mary は、フィードバックに関する質問がある場合、プルリクエスト内で応答し、質問を自分のフィーチャーのディスカッションフォーラムとして扱うことができます。
バグを修正するには、Mary は自分のフィーチャー ブランチに新しいコミットを追加し、最初に実行したように、そのコミットを自分の Bitbucket リポジトリにプッシュします 。コミットは、自動的にオリジナルのプルリクエストに追加され、John は、自分のオリジナルのコメントのすぐ隣で再度レビューできます。
John はプルリクエストを受け入れます。
最終的に、John は変更を承認してフィーチャー ブランチを main にマージし、プル リクエストのステータスを処理済みに変更します。これで、フィーチャーはプロジェクトに統合されました。作業中の他のあらゆる開発者は、標準の git pull コマンドを使用するだけで自分のローカル リポジトリにプルできます。
次のステップ
これで、プル リクエストを既存のワークフローに統合するために必要なすべてのツールが揃いました。プル リクエストは、Git ベースのコラボレーション ワークフローを置き換えるものではなく、チーム メンバー全員にとってコラボレーションをより利用しやすくする便利な追加機能です。
