プル リクエストのマージ

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

プル リクエストのマージ

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

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

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

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

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

    • Squash — ソース ブランチを宛先ブランチにマージする際にコミットを組み合わせます。
      このオプションは、コマンド ラインで「git merge --squash」と入力した場合と同じです。

      注: コマンド ラインにローカルで「git merge --squash」と入力すると、Bitbucket に変更をプッシュした後もプル リクエストは 'open' 状態のままになります。これは、コミット グラフを使用して変更の適用が検出されたこと、そして「squash merge」が使用されるとプル リクエストのマージの検出や正確な差分の表示を行えないためです。プル リクエストには 2 つのブランチ間で同じ変更が含まれるため、差分は表示されません。ただし、プル リクエストのコミット履歴を表示して個々のコミットを確認できます。

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

最終更新日 2021年08月25日)
次でキャッシュ 9:05 PM on Oct 21, 2021 |

その他のヘルプ