コミットをマージする
の pull request で既定の [pull request のマージ] オプションをクリックすると、機能ブランチからのすべてのコミットがマージ コミット内でベース ブランチに追� されます。 pull request は、--no-ff オプションを使用してマージされます。
pull request をマージするには、リポジトリの書き込みアクセス許可が必要です。
コミットをスカッシュしてマージする
の pull request で [スカッシュしてマージ] オプションを選択すると、その pull request のコミットは 1 つのコミットにスカッシュされます。 トピックブランチからコントリビュータの個々のコミットをすべて見る代わりに、コミットは１つのコミットにまとめられ、デフォルトブランチにマージされます。 スカッシュされたコミットを含む pull request は、早送りオプションを使用してマージされます。
pull request をスカッシュしてマージするには、リポジトリに書き込みアクセス許可が必要であり、リポジトリでスカッシュ マージが許可されている必要があります。
squashとマージは、よりス� ーズなGitの履歴をリポジトリに作り出すために利用できます。 作業途中でのコミットは、フィーチャブランチで作業しているときには役立ちますが、必ずしもGitの履歴に残すほど重要とはかぎりません。 デフォルトブランチへのマージに際してそれらのコミットを１つのコミットに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 してマージし続ける� �合は、同じコンフリクトを繰り返し解決する必要があります。
コミットをリベースしてマージする
の pull request で [リベースしてマージ] オプションを選択すると、トピック ブランチ (またはヘッド ブランチ) からのすべてのコミットが、マージ コミットなしに個別にベース ブランチに追� されます。 このように、リベースとマージの動作は、線形プロジェクト履歴を維持することで、早送りマージ に似ています。 しかし、リベースは、ベース ブランチのコミット履歴を新しいコミットで書き直すことでこれを実現します。
GitHub Enterprise Server でのリベースとマージの動作は、git rebase とは少し異なっています。 GitHub でリベースしてマージすると、常にコミッター情� �が更新され、新しいコミット SHA が作成されますが、GitHub 外の git rebase は、先祖コミットの上でリベースが発生した� �合、コミッター情� �は変更されません。 git rebase の詳細については、Git ドキュメントの「git-rebase」を参照してく� さい。
pull request をリベースしてマージするには、リポジトリに書き込みアクセス許可が必要であり、リポジトリでリベース マージが許可されている必要があります。
git rebase の視覚的表現については、ProGit ブックの「GitBranching-Rebasing」の� を参照してく� さい。
以下の� �合、上で自動的にリベースおよびマージすることはできません:
- プルリクエストにマージコンフリクトがある。
- ベースブランチからヘッドブランチへのコミットのリベースでコンフリクトが生じる。
- たとえば、マージコンフリクトなしにリベースできるものの、マージとは異なる結果が生成されるような� �合、コミットのリベースは「安全ではない」と考えられます。
それでもコミットをリベースしたいにもかかわらず、 上で自動的にリベースとマージが行えない� �合、以下のようにしなければなりません:
- トピックブランチ (あるいは head ブランチ) をベースブランチにローカルでコマンドラインからリベースする
- コマンド ラインでマージの競合を解決します。
- リベースされたコミットをプルリクエストのトピックブランチ (あるいはリモートの head ブランチ) にフォースプッシュする。
リポジトリに書き込み権限を持つ人は、続いて 上のリベース及びマージボタンを使って変更をマージできます。