Making a pull request

プルリクエストを実行する

プルリクエストは、開発者が Bitbucket を使ってコラボレーションを容易にする機能です。使いやすいウェブインターフェイスを備えており、提案された変更を公式プロジェクトに統合する前に議論することができます。

Git Workflows: Pull Request in Bitbucket

プルリクエストは、最も単純に言えば、開発者がフィーチャー開発作業の完了をチームメンバーに通知するメカニズムです。フィーチャーブランチの準備ができた時点で、開発者は Bitbucket アカウントを使いプルリクエストを送信します。これにより、関係者全員はそのコードをレビューし、master ブランチにマージする必要があることが知らされます。

しかし、プルリクエストは単なる通知機能ではありません。提案されたフィーチャーを議論するための専用フォーラムです。変更に何か問題があれば、プルリクエストに対してチームメンバーがフィードバックを投稿し、追加コミットをプッシュすることでフィーチャーを微調整することも可能です。このすべての内容をプルリクエストで直接トラッキングできます。

Git Workflows: Activity inside a pull request

この正規のコミット共有ソリューションは、他のコラボレーションモデルと比べて非常に無駄のないワークフローです。SVN や Git でも、単純なスクリプトを使って通知メールを自動送信できます。しかし、変更の議論に関しては、開発者はメールスレッドに頼らざるを得ないことが多く、追加コミットが関わってくる場合などに混乱したものにもなりえます。プルリクエストは、使いやすいウェブインターフェイスで、この機能をすべて Bitbucket リポジトリのすぐ隣に表示します。

プルリクエストの構造

プルリクエストを送信する際に行うことは、他の開発者 (例: プロジェクトメンテナー) が自分のリポジトリから開発者のリポジトリへブランチをプルするようにリクエストすることだけです。つまり、プルリクエストを送信するには、マージ元リポジトリ、マージ元ブランチ、マージ先リポジトリ、マージ先ブランチの 4 つの情報を提供する必要があります。

Git Workflows: Pull Requests

これら変数の多くは、Bitbucket によって適切なデフォルト値に設定されます。しかし、利用しているコラボレーションワークフローによって異なる変数を指定する必要がある場合もあります。上記の図は、あるフィーチャーブランチの公式 master ブランチへのマージを要請するプルリクエストを表しています。しかし、プルリクエストを使う方法は他にも数多くあります。

仕組み

プルリクエストは、フィーチャーブランチワークフローGitflow ワークフロー、またはフォーク型ワークフローと組み合わせて使用できます。ただし、プルリクエストには 2 つの個別のブランチまたは 2 つの個別のリポジトリが必要なため、集中化ワークフローでは機能しません。これらの各ワークフローでプルリクエストを使用する方法は少し異なりますが、一般的なプロセスは次のとおりです。

  1. 開発者は、ローカルリポジトリの専用ブランチにこの機能を作成します。

  2. 開発者は、このブランチを公開の Bitbucket リポジトリにプッシュします。

  3. 開発者は、Bitbucket でプルリクエストを送信します。

  4. チームの残りのメンバーはコードをレビューし、話し合い、変更します。

  5. プロジェクトメンテナーは、その機能を公式リポジトリにマージし、プルリクエストをクローズします。

このセクションの残りの部分では、さまざまなコラボレーションワークフローに対してどのようにプルリクエストを活用できるかについて説明します。

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

フィーチャーブランチワークフローでは、Bitbucket 共有リポジトリを使用してコラボレーションを管理し、開発者は独立したブランチにフィーチャーを作成します。フィーチャーは master に直ちにマージされるのではなく、開発者はプルリクエストを送信し、メインデーターベースへの統合前に、フィーチャーに関する議論を開始すべきです。

Pull Request: Feature Branch workflow

フィーチャーブランチワークフローでは、公開リポジトリは 1 つだけです。プルリクエストのマージ先リポジトリと、マージ元リポジトリは常に同じになります。通常、開発者はフィーチャーブランチをマージ元ブランチとして指定し、master ブランチをマージ先ブランチと指定します。

プルリクエストを受け取った後、プロジェクトメンテナーは対応を決定する必要があります。フィーチャーがマージできる状態であれば、master にマージし、プルリクエストのステータスを処理済みに変更するだけです。もし、提案された変更に問題があれば、プルリクエストにフィードバックを投稿できます。その後、関連コメントのすぐ隣に追加コミットが表示されます。

未完成のフィーチャーのプルリクエストを送信することもできます。たとえば、開発者が特定の機能の実装に行き詰まった時、作業中のフィーチャーのプルリクエストを送信できます。他の開発者はそのプルリクエストに助言を提供し、追加コミットで問題を修正することも可能です。

Gitflow ワークフローでのプルリクエスト

Gitflow ワークフローはフィーチャーブランチワークフローに類似していますが、プロジェクトのリリースに関連した利用を想定して設計された厳密なブランチ モデルを定義しています。Gitflow ワークフローにプルリクエストを追加すると、作業中の開発者にリリースブランチやメンテナンスブランチに関して議論する便利な場を提供できます。

Pull Requests: Gitflow Workflow Pull Requests: Gitflow Workflow 2

Gitflow ワークフローでのプルリクエストの構造は、前項とまったく同じです。開発者は、フィーチャー/リリース/hotfix ブランチに対するレビューが必要な時にプルリクエストを送信するだけです。他のチームメンバーには Bitbucket で通知が届きます。

一般的に、フィーチャーは develop ブランチにマージされます。一方、リリースと hotfix ブランチは developmaster の両方にマージされます。これらのマージすべてを公式に管理するためにプルリクエストを使うことができます。

フォーク型ワークフローでのプルリクエスト

フォーク型ワークフローでは、開発者は完了したフィーチャーを共有リポジトリではなく自分の公開リポジトリにプッシュします。その後、プルリクエストを送信して、レビューの準備ができたことをプロジェクトメンテナーに通知します。

プロジェクトメンテナーは、他の開発者それぞれが独自の Bitbucket リポジトリにコミットを追加したことを知る手段はないので、このワークフローでは、プルリクエストの通知機能が特に役立ちます。

Pull Requests: Forking workflow

開発者はそれぞれ自分の公開リポジトリを持っているので、プルリクエストのマージ元リポジトリはマージ先リポジトリとは別のものになります。マージ元リポジトリは開発者の公開リポジトリ、マージ元ブランチは変更提案を含むブランチとなります。開発者がフィーチャーを公式リポジトリにマージしようとする場合、マージ先リポジトリは公式プロジェクトとなり、マージ先ブランチは master となります。

プルリクエストは、公式プロジェクト以外の他の開発者とのコラボレーションにも使用できます。たとえば、開発者がチームメンバーと一緒にフィーチャーを作業する場合、公式プロジェクトの代わりにチームメンバーの Bitbucket リポジトリをマージ先として使用してプルリクエストを送信できます。その場合、マージ元とマージ先のブランチに同じフィーチャーブランチを使用します。

Pull Requests: Forking workflow

2 人の開発者は、プルリクエスト内でフィーチャーについて話し合い、開発することができました。完了すると、そのうちの 1 人が、そのフィーチャーを公式の master ブランチにマージするよう求める別のプルリクエストを申請します。このような柔軟性により、フォーク型ワークフローではプルリクエストが非常に強力なコラボレーションツールになります。

以下の例は、フォーク型ワークフローでどのようにプルリクエストを使用できるかを示しています。これは、小規模なチームで作業する開発者やオープンソースプロジェクトに貢献しているサードパーティの開発者にも同様に適用できます。

この例では、Mary は開発者であり、John はプロジェクトメンテナーです。どちらも独自の公開の Bitbucket リポジトリを持ち、John のリポジトリには公式プロジェクトが含まれています。

Mary が公式リポジトリをフォークします。

Pull Requests: Fork the project

プロジェクトの作業を開始するには、まず Mary が John の Bitbucket リポジトリをフォークする必要があります。これを行うには、Bitbucket にサインインし、John のリポジトリに移動して、[フォーク] ボタンをクリックします。

Pull Request: Fork in Bitbucket

フォークしたリポジトリに名前と説明を記入したら、Mary はサーバー側にこのプロジェクトのコピーを保有することになります。

Mary がフォークした Bitbucket リポジトリをクローンします

Pull Request: Clone the Bitbucket repo

次に、Mary はフォークした Bitbucket リポジトリをクローンする必要があります。クローンにより、Mary はローカルマシンに作業用のプロジェクトのコピーを保有することになります。Mary が使用するコマンドは次のようになります。

git clone https://user@bitbucket.org/user/repo.git

git clone は、Mary のフォークされたリポジトリを指す origin リモートを自動的に作成します。

Mary が新しいフィーチャーを作成します。

Pull Requests: develop a new feature

Mary はコードを書き始める前にまず、作業フィーチャー用に新しいブランチを作成する必要があります。このブランチは、Mary によってプルリクエストのマージ元ブランチとして使われることになります。

git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"

Mary は、必要な数だけコミットを使用してフィーチャーを作成できます。また、フィーチャーの履歴が思ったよりも乱雑な場合は、インタラクティブリベースを使用して不要なコミットを削除またはスカッシュできます。大規模プロジェクトでは、フィーチャーの履歴をクリーンアップすることで、プロジェクトメンテナーはプルリクエストで何が起こっているのかを簡単に確認できます。

Mary が自分の Bitbucket リポジトリにフィーチャーをプッシュします

Pull Requests: Push feature to Bitbucket repository

フィーチャー開発が完了したら、Mary は git push を実行するだけで、フィーチャーブランチを自分の Bitbucket リポジトリ (公式リポジトリとは別) にプッシュできます。

git push origin some-branch

これで、プロジェクトメンテナー (または、変更を入手する必要がある他のコラボレーター) は Mary の変更を見ることができるようになります。

Mary がプルリクエストを作成します

Pull Request: Create Pull Request

Bitbucket で自分のフィーチャーブランチが設定されると、Mary は Bitbucket アカウントからフォークされたリポジトリに移動し、右上隅にある [プルリクエスト] ボタンをクリックすることで、プルリクエストを作成できます。結果のフォームは Mary のリポジトリを自動的にマージ元として設定し、Mary はマージ元ブランチ、マージ先リポジトリ、マージ先ブランチを指定するように求められます。

Mary は自分のフィーチャーを公式リポジトリにマージしたいので、マージ元ブランチは Mary のフィーチャーブランチ、マージ先リポジトリは John の公開リポジトリ、マージ先ブランチは master となります。また、Mary はプルリクエストに対してタイトルと説明を入力する必要もあります。John 以外にコードを承認する必要がある人が他にもいる場合は、[レビュアー] フィールドを追加できます。

Pull Request: Bitbucket

Mary がプルリクエストを作成した後、Bitbucket フィードを介して John に通知が送信されます (オプションでメールでも通知されます)。

John はプルリクエストをレビューします。

Pull Request: Bitbucket pull requests

John は、自分の Bitbucket リポジトリの [プルリクエスト] タブをクリックすると、送信されたすべてのプルリクエストにアクセスできます。Mary のプルリクエストをクリックすると、プルリクエストの説明、フィーチャーのコミット履歴、含まれているすべての変更の差分が表示されます。

Mary のフィーチャーはプロジェクトにマージできるものだと John が考えれば、[マージ] ボタンをクリックするだけで、プルリクエストを承認し、Mary のフィーチャーは John の master ブランチにマージされます。

しかし、たとえば、John が Mary のコードに小さなバグを発見し、マージ前に Mary にそのバグを修正させる必要があるとします。この場合、John は、プルリクエスト全体に対してコメントを投稿するか、または、フィーチャー履歴の特定のコミットを選択してコメントを書くことができます。

Pull Request: Comment

Mary はフォローアップコミットを追加します。

Mary は、フィードバックに関する質問がある場合、プルリクエスト内で応答し、質問を自分のフィーチャーのディスカッションフォーラムとして扱うことができます。

バグを修正するには、Mary は自分のフィーチャーブランチに新しいコミットを追加し、最初に実行したように、そのコミットを自分の Bitbucket リポジトリにプッシュします。コミットは、自動的にオリジナルのプルリクエストに追加され、John は、自分のオリジナルのコメントのすぐ隣で再度レビューできます。

John はプルリクエストを受け入れます。

最終的に、John は変更を承認し、フィーチャーブランチを公式リポジトリにマージし、プルリクエストのステータスを処理済みに変更します。これで、プロジェクトへの Mary のフィーチャーの統合は完了です。作業中の他のあらゆる開発者は標準の git pull コマンドを使うだけで、自分のローカルリポジトリにプルすることができます。

次のステップ

これで、プルリクエストを既存のワークフローに統合するために必要なすべてのツールが揃いました。プルリクエストは、Git ベースのコラボレーションワークフローを置き換えるものではなく、チームメンバー全員にとってコラボレーションをより利用しやすくする便利な追加機能です。

プルリクエストを試してみましょう。

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

今すぐ始める