your GitHub Enterprise Server instance上のプルリクエストでデフォルトのMerge pull request(プルリクエストのマージ)オプションをクリックすると、フィーチャブランチからのすべてのコミットがマージコミット内でベースブランチに追加されます。 プルリクエストは、--no-ff
オプションを使ってマージされます。
プルリクエストをマージするためには、リポジトリの書き込み権限を持っていなければなりません。
プルリクエストのコミットのsquashとマージ
your GitHub Enterprise Server instance上のプルリクエストでSquash and merge(squashとマージ)オプションを選択すると、そのプルリクエストのコミットは1つのコミットにsquashされます。 トピックブランチからコントリビュータの個々のコミットをすべて見る代わりに、コミットは1つのコミットにまとめられ、デフォルトブランチにマージされます。 squashされたコミットを持つプルリクエストは、fast-forwardオプションを使ってマージされます。
プルリクエストをsquashしてマージするには、リポジトリへの書き込み権限を持っていなければならず、リポジトリではsquashマージが許可されていなければなりません。
squashとマージは、よりスムーズなGitの履歴をリポジトリに作り出すために利用できます。 作業途中でのコミットは、フィーチャブランチで作業しているときには役立ちますが、必ずしもGitの履歴に残すほど重要とはかぎりません。 デフォルトブランチへのマージに際してそれらのコミットを1つのコミットにsquashすれば、明快なGitの履歴と共にオリジナルの変更を残しておけます。
squash マージのマージメッセージ
squash してマージすると、GitHub はコミットメッセージを生成します。メッセージは必要に応じて変更できます。 メッセージのデフォルトは、プルリクエストに複数のコミットが含まれているか、1 つだけ含まれているかによって異なります。
コミット数 | 概要 | 説明 |
---|---|---|
単一のコミット | 単一のコミットのコミットメッセージのタイトルと、その後に続くプルリクエスト番号 | 単一のコミットのコミットメッセージの本文テキスト |
複数のコミット | プルリクエストのタイトルと、その後に続くプルリクエスト番号 | squash されたすべてのコミットのコミットメッセージの日付順のリスト |
長時間にわたるブランチを squash してマージする
プルリクエストがマージされた後、プルリクエストの head ブランチで作業を継続する場合は、プルリクエストを squash してマージしないことをお勧めします。
プルリクエストを作成すると、GitHub は、head ブランチとベースブランチの両方にある最新のコミット、つまり共通の先祖のコミットを識別します。 プルリクエストを squash してマージすると、GitHub は、共通の先祖のコミット以降に head ブランチで行ったすべての変更を含むコミットをベースブランチに作成します。
このコミットはベースブランチのみで行われ、head ブランチでは行われないため、2 つのブランチの共通の先祖は変更されません。 head ブランチでの作業を続行し、2 つのブランチ間に新しいプルリクエストを作成すると、プルリクエストには、共通の先祖以降のすべてのコミットが含まれます。これには、前のプルリクエストで squash してマージしたコミットも含まれます。 コンフリクトがない場合は、これらのコミットを安全にマージできます。 ただし、このワークフローでは高確率でマージコンフリクトが発生します。 長時間にわたる head ブランチのプルリクエストを squash してマージし続ける場合は、同じコンフリクトを繰り返し解決する必要があります。
プルリクエストコミットのリベースとマージ
your GitHub Enterprise Server instance上のプルリクエストでRebase and merge(リベースとマージ)オプションを選択すると、トピックブランチ(あるいはheadブランチ)のすべてのコミットが、マージコミットなしに個別にベースブランチに追加されます。 リベースされたコミットを持つプルリクエストは、fast-forwardオプションを使ってマージされます。
プルリクエストをリベースしてマージするには、リポジトリへの書き込み権限が必要で、リポジトリではリベースマージが許可されていなければなりません。
GitHub Enterprise Server上でのリベースとマージの振る舞いは、gitのリベース
とは少し異なっています。 GitHub上でのリベースとマージは、常にコミッターの情報を更新し、新しいSHAを生成しますが、GitHub外でのgit rebase
は祖先のコミット上でリベースが生じたときにコミッター情報を変更しません。 For more information about git rebase
, see the official Git documentation.
git rebase
の視覚的な表現については、書籍Pro Gitの"Git Branching - Rebasing"の章を参照してください。
以下の場合、your GitHub Enterprise Server instance上で自動的にリベースおよびマージすることはできません:
- プルリクエストにマージコンフリクトがある。
- ベースブランチからヘッドブランチへのコミットのリベースでコンフリクトが生じる。
- たとえば、マージコンフリクトなしにリベースできるものの、マージとは異なる結果が生成されるような場合、コミットのリベースは「安全ではない」と考えられます。
それでもコミットをリベースしたいにもかかわらず、your GitHub Enterprise Server instance 上で自動的にリベースとマージが行えない場合、以下のようにしなければなりません:
- トピックブランチ (あるいは head ブランチ) をベースブランチにローカルでコマンドラインからリベースする
- コマンドライン上でマージコンフリクトを解決する
- リベースされたコミットをプルリクエストのトピックブランチ (あるいはリモートの head ブランチ) にフォースプッシュする。
リポジトリに書き込み権限を持つ人は、続いてyour GitHub Enterprise Server instance上のリベース及びマージボタンを使って変更をマージできます。