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

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-06-03. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてく� さい。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してく� さい。

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

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 Enterprise Serverインスタンス上のプルリクエストでデフォルトのMerge pull request(プルリクエストのマージ)オプションをクリックすると、フィーチャブランチからのすべてのコミットがマージコミット内でベースブランチに追� されます。 プルリクエストは、--no-ffオプションを使ってマージされます。

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

standard-merge-commit-diagram

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

GitHub Enterprise Serverインスタンス上のプルリクエストで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 されたすべてのコミットのコミットメッセージの日付� �のリスト

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

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

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

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

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

GitHub Enterprise Serverインスタンス上のプルリクエストで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 Server上でのリベースとマージの振る舞いは、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 Enterprise Serverインスタンス上で自動的にリベースおよびマージすることはできません:

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

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

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

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

参考リンク