Skip to main content
ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

プルリクエストのマージについて

You can merge pull requests by retaining all the commits in a feature branch, squashing all commits into a single commit, or by rebasing individual commits from the head branch onto the base branch.

GitHub.com上のプルリクエストでデフォルトのMerge pull request(プルリクエストのマージ)オプションをクリックすると、フィーチャブランチからのすべてのコミットがマージコミット内でベースブランチに追加されます。 プルリクエストは、--no-ffオプションを使ってマージされます。

プルリクエストをマージするためには、リポジトリの書き込み権限を持っていなければなりません。

standard-merge-commit-diagram

プルリクエストのコミットのsquashとマージ

GitHub.com上のプルリクエストでSquash and merge(squashとマージ)オプションを選択すると、そのプルリクエストのコミットは1つのコミットにsquashされます。 トピックブランチからコントリビュータの個々のコミットをすべて見る代わりに、コミットは1つのコミットにまとめられ、デフォルトブランチにマージされます。 squashされたコミットを持つプルリクエストは、fast-forwardオプションを使ってマージされます。

プルリクエストをsquashしてマージするには、リポジトリへの書き込み権限を持っていなければならず、リポジトリではsquashマージが許可されていなければなりません。

commit-squashing-diagram

squashとマージは、よりスムーズなGitの履歴をリポジトリに作り出すために利用できます。 作業途中でのコミットは、フィーチャブランチで作業しているときには役立ちますが、必ずしもGitの履歴に残すほど重要とはかぎりません。 デフォルトブランチへのマージに際してそれらのコミットを1つのコミットにsquashすれば、明快なGitの履歴と共にオリジナルの変更を残しておけます。

squash マージのマージメッセージ

When you squash and merge, GitHub generates a default commit message, which you can edit. The default message depends on the number of commits in the pull request, not including merge commits.

コミット数概要説明
単一のコミット単一のコミットのコミットメッセージのタイトルと、その後に続くプルリクエスト番号単一のコミットのコミットメッセージの本文テキスト
複数のコミットプルリクエストのタイトルと、その後に続くプルリクエスト番号squash されたすべてのコミットのコミットメッセージの日付順のリスト

People with admin access to a repository can configure the repository to use the title of the pull request as the default merge message for all squashed commits. For more information, see "Configure commit squashing".

長時間にわたるブランチを squash してマージする

プルリクエストがマージされた後、プルリクエストの head ブランチで作業を継続する場合は、プルリクエストを squash してマージしないことをお勧めします。

プルリクエストを作成すると、GitHub は、head ブランチとベースブランチの両方にある最新のコミット、つまり共通の先祖のコミットを識別します。 プルリクエストを squash してマージすると、GitHub は、共通の先祖のコミット以降に head ブランチで行ったすべての変更を含むコミットをベースブランチに作成します。

このコミットはベースブランチのみで行われ、head ブランチでは行われないため、2 つのブランチの共通の先祖は変更されません。 head ブランチでの作業を続行し、2 つのブランチ間に新しいプルリクエストを作成すると、プルリクエストには、共通の先祖以降のすべてのコミットが含まれます。これには、前のプルリクエストで squash してマージしたコミットも含まれます。 コンフリクトがない場合は、これらのコミットを安全にマージできます。 ただし、このワークフローでは高確率でマージコンフリクトが発生します。 長時間にわたる head ブランチのプルリクエストを squash してマージし続ける場合は、同じコンフリクトを繰り返し解決する必要があります。

プルリクエストコミットのリベースとマージ

GitHub.com上のプルリクエストでRebase and merge(リベースとマージ)オプションを選択すると、トピックブランチ(あるいはheadブランチ)のすべてのコミットが、マージコミットなしに個別にベースブランチに追加されます。 In that way, the rebase and merge behavior resembles a fast-forward merge by maintaining a linear project history. However, rebasing achieves this by re-writing the commit history on the base branch with new commits.

GitHub Enterprise Cloud上でのリベースとマージの振る舞いは、gitのリベースとは少し異なっています。 GitHub上でのリベースとマージは、常にコミッターの情報を更新し、新しいSHAを生成しますが、GitHub外でのgit rebaseは祖先のコミット上でリベースが生じたときにコミッター情報を変更しません。 For more information about git rebase, see git-rebase in the Git documentation.

プルリクエストをリベースしてマージするには、リポジトリへの書き込み権限が必要で、リポジトリではリベースマージが許可されていなければなりません。

git rebaseの視覚的な表現については、書籍Pro Gitの"Git Branching - Rebasing"の章を参照してください。

以下の場合、GitHub.com上で自動的にリベースおよびマージすることはできません:

  • プルリクエストにマージコンフリクトがある。
  • ベースブランチからヘッドブランチへのコミットのリベースでコンフリクトが生じる。
  • たとえば、マージコンフリクトなしにリベースできるものの、マージとは異なる結果が生成されるような場合、コミットのリベースは「安全ではない」と考えられます。

それでもコミットをリベースしたいにもかかわらず、GitHub.com 上で自動的にリベースとマージが行えない場合、以下のようにしなければなりません:

  • トピックブランチ (あるいは head ブランチ) をベースブランチにローカルでコマンドラインからリベースする
  • コマンドライン上でマージコンフリクトを解決する
  • リベースされたコミットをプルリクエストのトピックブランチ (あるいはリモートの head ブランチ) にフォースプッシュする。

リポジトリに書き込み権限を持つ人は、続いてGitHub.com上のリベース及びマージボタンを使って変更をマージできます。

参考リンク