pull request のマージ

作業が完了したら、pull request を上流ブランチにマージします。 リポジトリに対してプッシュアクセスを持つユーザなら誰でもマージを実行できます。

Tool navigation

この記事の内容

pull request のマージについて

pull request では、head ブランチに加えた変更をベースブランチにマージすることを提案します。 デフォルトでは、head ブランチがベースブランチとコンフリクトしていない限り、どの pull request もいつでもマージできます。 ただし、pull request を特定のブランチにマージできるタイミングには制限がある場合があります。 たとえば、必須のステータスチェックに合格した場合にのみ、pull request をデフォルトブランチにマージできます。 リポジトリ管理者は、ブランチ保護ルールを使用して、ブランチにこのような制約を追加できます。 詳しくは、「保護されたブランチについて」をご覧ください。

ブランチ保護規則の代わりに、ルールセットを作成できます。 ルールセットには、状態など、ブランチの保護ルールよりもいくつかの利点があり、管理者アクセスを必要とせずに検出可能性が向上します。 同時に複数のルールセットを適用することもできます。 詳しくは、「ルールセットについて」を参照してください。

すべてのマージの要件が満たされたときに、自動的にマージされるようにPull Requestを設定できます。 詳しくは、「プルリクエストを自動的にマージする」を参照してください。

pull request でマージ コンフリクトが発生する場合、またはマージの前に変更をテストしたい場合は、コマンドラインを使用して、pull request をローカルでチェックアウトしてマージすることができます。

ドラフトの pull request をマージすることはできません。 ドラフトの pull request の詳細については、「pull requests について」を参照してください。

pull request をマージすると pull request の head ブランチが自動的に削除されるようにリポジトリを設定できます。 詳しくは、「ブランチの自動的削除を管理する」をご覧ください。

Note

プルリクエストがマージされた後にheadブランチを削除すると、GitHubは同じリポジトリ内に削除されたブランチをベースブランチと指定しているオープンなプルリクエストがないかをチェックします。 GitHubはそういったプルリクエストを自動的に更新し、ベースブランチをマージされたプルリクエストのベースブランチに変更します。詳細については、「ブランチの概要」を参照してください。

pull request は、高速転送オプションを使用してマージされる、スカッシュまたはリベースされるコミットを含む pull request を除き、 --no-ffオプションを使用してマージされます。

pull request をイシューにリンクして、修正が進行中であることを示し、誰かが pull request をマージしたときイシューを自動的にクローズすることができます。 詳しくは、「Pull RequestをIssueにリンクする」を参照してください。

トピック ブランチでの変更を上流ブランチにマージしない場合は、マージせずに pull request をクローズすることができます。

プル要求のマージ

  1. リポジトリ名の下にある [pull request] をクリックします。

    リポジトリのメイン ページのスクリーンショット。 水平ナビゲーション バーでは、[pull request] というラベルが付いたタブが濃いオレンジ色の枠線で囲まれています。

  2. [Pull Requests] リストで、マージしたい pull request をクリックします。

  3. pull request 一番下までスクロールしてください。 リポジトリで有効なマージオプションに応じて、以下の操作が可能です:

    Note

    リベースとコミットを行うと、常にコミッターの情報が更新され、新しいコミット SHA が作成されます。 詳細については、「pull request のマージについて」を参照してください。

  4. 要求されたら、コミットメッセージを入力するか、デフォルトのメッセージのままにします。

    スカッシュ マージの既定のコミット メッセージの詳細については、「プルリクエストのマージについて」を参照してください。

  5. GitHub のアカウントに複数のメール アドレスが関連付けられている場合は、[メール アドレス] ドロップダウン メニューをクリックし、Git 作成者のメール アドレスとして使用するメール アドレスを選択します。 このドロップダウンメニューには、検証済みのメールアドレスだけが表示されます。 メール アドレスのプライバシーを有効にした場合は、no-reply がコミット作成者の既定のメール アドレスになります。 no-reply メール アドレスの正確な形式については、「コミットメールアドレスを設定する」を参照してください。

    GitHub pull request のスクリーンショット。コミット作成者のメール アドレスを選ぶためのオプションを含む、ドロップダウン メニューが表示されています。 octocat@github.com が選ばれています。

    Note

    リベース マージの場合 (マージ コミットは作成されません)、メール セレクターを使用できません。 スカッシュ マージの場合、自分が pull request の作成者であり、自分のアカウントに関連付けられたメール アドレスが複数ある場合にのみ、メール セレクターが表示されます。

  6. [マージを確認する] 、 [スカッシュとマージを確認する] または [リベースとマージを確認する] をクリックします。

  7. 必要に応じて、ブランチを削除します。 こうすることで、リポジトリにあるブランチのリストが整理された状態を保てます。

Note

GitHub CLI について詳しくは、「GitHub CLI について」をご覧ください。

pull request をマージするには、gh pr merge サブコマンドを使用します。 pull-request を、pull request の番号、URL、またはヘッド ブランチと置き換えます。

gh pr merge PULL-REQUEST

対話型のプロンプトに従って、マージを完了します。 選択できるマージ メソッドの詳細については、「プルリクエストのマージについて」を参照してください。

または、フラグを使用して対話型のプロンプトをスキップすることができます。 たとえば、このコマンドはコミット メッセージ "my squash commit" を使用してコミットを 1 つのコミットにスカッシュし、スカッシュされたコミットをベース ブランチにマージしてから、ローカルおよびリモート ブランチを削除します。

gh pr merge 523 --squash --body "my squash commit" --delete-branch

参考資料