プル リクエストのマージ

指定された数のレビュアーがプル リクエストを承認すると、リポジトリの書き込み (または管理) 権限を持っているユーザーがそのプル リクエストをマージできます。別のユーザーと同じコードを操作していた場合、マージの競合が発生し、それをローカルで解決する必要がある場合があります。プル リクエストをマージした後、プル リクエストを戻してリポジトリからマージ コミットを削除できます。

プル リクエストのマージ

変更のマージは、プル リクエスト プロセスの最後の段階です。プル リクエストをマージするには、次の手順を実行します。

  1. マージ ボタンをクリックします。

  2. (オプション) コミット メッセージに詳細を追加して更新します。

  3. (Git リポジトリのみ) [マージ戦略] を次のオプションから選択します。

    • Merge commit — ソース ブランチのすべてのコミットを保持し、それらを宛先ブランチの一部にします。
      このオプションは、コマンド ラインで「git merge --no-ff」と入力した場合と同じです。

    • Squash—Combines your commits when you merge the source branch into the destination branch.
      This option is the same as entering git merge --squash in the command line.

      Note: When you enter git merge --squash in the command line locally, the pull request will remain in the ‘open’ state after you push the changes to Bitbucket. This is because we use the commit graph to detect that changes were applied, and when ‘squash merge’ is used, we cannot detect that the pull request was merged or display an accurate diff. The pull request will now contain identical changes between the two branches, so the pull request will show no diff. However, you will be able to see the commit history of the pull request and view the individual commits.

    • Fast forward — コミットをソース ブランチから宛先ブランチに移動させます (宛先に新しいコミットがない場合)。
      このオプションは、コマンド ラインで「git merge --ff-only」と入力した場合と同じです。

    これら 2 つのタイプのマージ戦略の詳細については、以下のマージ戦略を参照してください。

  4. (オプション) 同じリポジトリ内の 2 つのブランチをマージする場合、[ソース ブランチをクローズする] チェックボックスを選択して、リポジトリ ブランチの一覧からブランチを削除できます。

  5. マージ ボタンをクリックします。

また、Bitbucket は、マージしているブランチからのコミットのみで構成された他のプル リクエストも「マージ済み」としてマークします。たとえば、別のオープン プル リクエストがマージしているブランチに基づいていて追加のコミットがない場合は、もう一方のオープン プル リクエストも「マージ済み」とマークされます。

マージ チェックリスト

マージ チェックリストをセットアップする方法

リポジトリ管理者は、リポジトリにマージ チェックリストを追加できます。詳細は、「マージ前にチェックを提案または要求する」を参照してください。

プル リクエストをマージしようとしたときに、マージ チェックリストが表示されることがあります。このチェックリストは、コードのマージ前に解決するように管理者が要求している項目の一覧です。 警告ラベルが表示されたチェックリスト項目は未解決です。

組織が Premium プランである場合、ワークスペース管理者はプル リクエストをマージする前に、マージ チェックが解決済みであることを要求できます。

このチェックリスト項目に警告ラベルが表示されている場合:

プル リクエストの状態

{#} 件以上の承認

承認数がその数を満たしていない

最後のコミットで {#} 件以上のビルドに成功

最後のコミットで成功したビルドがその数を満たしていない

最後のコミットですべてのビルドに成功

最後のコミットに失敗したビルドがある

プル リクエスト タスクが解決済み

オープンなプルリクエスト タスクがある

マージ チェックを表示する

プル リクエストの管理者またはレビュアーは、右側のサイドバーの上部にあるマージ チェック パネルでマージ チェック (必須または任意) を表示して、プル リクエストを承認する前に、完了したものと未完了のものを確認できます。

マージ戦略

マージ戦略は、プル リクエストをマージする際の、コミット履歴の表示方法を定義します。いずれの戦略も、ソース ブランチのすべてのコミットを宛先ブランチにマージします。ワークスペースに対して作成したワークフローやリポジトリの使用方法に応じて戦略のタイプを選択します。

マージ コミットを使用するタイミング

正確な変更履歴を保持したい場合は [マージ コミット] を選択します。マージ コミットは、使用しているワークフローの一環として、プル リクエストの範囲が広く、個々のコミットのレビューが必要な場合にも便利です。この戦略はマージの際にすべてのコミットを保持するため、[コミット] ページでソース ブランチのすべてのコミットを引き続き表示できます。

マージ スカッシュを実行するタイミング

[スカッシュ] を選択してコミットを簡素化させると、バグの原因となるコミットを探す時間を削減し (git bisect を使用)、追跡しやすいコミット履歴を実現できます。この戦略はマージする際にすべてのコミットを組み合わせるため、[コミット] ページの宛先ブランチには 1 つのコミットのみが表示されます。

ファストフォワード マージを使用するタイミング

ソース ブランチの作成以降に宛先ブランチに新しいコミットがない場合は、[ファストフォワード] を選択します。ファストフォワード マージは、ソース ブランチの先頭を宛先ブランチの先頭へと移動させ、コミット履歴を統合します。この戦略はソース ブランチのすべてのコミットを宛先コミットへと移動するため、[コミット] ページ上には引き続きすべてのコミットが表示されます。

マージされたプル リクエストを戻す

プル リクエストを元に戻すことはできませんが、プル リクエストによってマージされたコミットを必要に応じて戻すことはできます。Bitbucket はプル リクエストの巻き戻し処理を 2 ステップで実行します。1) Bitbucket はマージされたコミットを戻す 1 つのコミットを持つ、新しいブランチを作成します。2) Bitbucket はそのブランチおよびコミットに対する新しいプル リクエストを作成します。

プル リクエストを戻すには、次の手順を実行します。

  1. プル リクエストでから、右上の [元に戻す] ボタンをクリックします。

  2. (オプション) [プル リクエストを元に戻す] ダイアログで、作成しようとしている新しいブランチのブランチ名にブランチ名を変更します。

  3. [元に戻す] ボタンをクリックします。 [元に戻す] をクリックすると、Bitbucket によって新しいブランチが作成されます。プル リクエストをキャンセルした場合でも、元に戻されたブランチはリポジトリ内に残ります。

  4. [プル リクエストを作成] ページが開き、元に戻されたブランチがソースとして表示されます。レビュワーを追加して変更を加えた後、[作成] をクリックします。

その他のヘルプ