Skip to main content

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

フィーチャー ブランチにすべてのコミットを保持して、すべてのコミットを単一のコミットに squash するか、個々のコミットを head ブランチから base ブランチにリベースして、pull request をマージできます。

コミットをマージする

your GitHub Enterprise Server instance の pull request で既定の [pull request のマージ] オプションをクリックすると、機能ブランチからのすべてのコミットがマージ コミット内でベース ブランチに追加されます。 pull request は、--no-ff オプションを使用してマージされます。

pull request をマージするには、リポジトリの書き込みアクセス許可が必要です。

standard-merge-commit-diagram

コミットをスカッシュしてマージする

your GitHub Enterprise Server instance の pull request で [スカッシュしてマージ] オプションを選択すると、その pull request のコミットは 1 つのコミットにスカッシュされます。 トピックブランチからコントリビュータの個々のコミットをすべて見る代わりに、コミットは1つのコミットにまとめられ、デフォルトブランチにマージされます。 スカッシュされたコミットを含む pull request は、早送りオプションを使用してマージされます。

pull request をスカッシュしてマージするには、リポジトリに書き込みアクセス許可が必要であり、リポジトリでスカッシュ マージが許可されている必要があります。

commit-squashing-diagram

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

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

スカッシュしてマージすると、GitHub によって既定のコミット メッセージが生成されます。これを編集することができます。 既定のメッセージは、pull request 内のコミットの数によって異なります (マージ コミットは含まれません)。

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

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

pull request のマージ後、pull request のヘッド ブランチでの作業を続ける場合、pull request はスカッシュしてマージしないことをお勧めします。

pull request を作成すると、GitHub によって、ヘッド ブランチとベース ブランチの両方での最近のコミットが特定されます。共通の先祖のコミットです。 プルリクエストを squash してマージすると、GitHub は、共通の先祖のコミット以降に head ブランチで行ったすべての変更を含むコミットをベースブランチに作成します。

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

コミットをリベースしてマージする

your GitHub Enterprise Server instance の pull request で [リベースしてマージ] オプションを選択すると、トピック ブランチ (またはヘッド ブランチ) からのすべてのコミットが、マージ コミットなしに個別にベース ブランチに追加されます。 このように、リベースとマージの動作は、線形プロジェクト履歴を維持することで、早送りマージ に似ています。 しかし、リベースは、ベース ブランチのコミット履歴を新しいコミットで書き直すことでこれを実現します。

GitHub Enterprise Server でのリベースとマージの動作は、git rebase とは少し異なっています。 GitHub でリベースしてマージすると、常にコミッター情報が更新され、新しいコミット SHA が作成されますが、GitHub 外の git rebase は、先祖コミットの上でリベースが発生した場合、コミッター情報は変更されません。 git rebase の詳細については、Git ドキュメントの「git-rebase」を参照してください。

pull request をリベースしてマージするには、リポジトリに書き込みアクセス許可が必要であり、リポジトリでリベース マージが許可されている必要があります。

git rebase の視覚的表現については、ProGit ブックの「GitBranching-Rebasing」の章を参照してください。

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

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

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

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

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

参考資料