上でプルリクエストのマージオプションを設定して、ワークフローの要求と Git の履歴管理への要望を満たすことができます。 詳細については、「pull request マージの構成」を参照してく� さい。コミットsquashingあるいはリベースのようなマージの1つの種類を、リポジトリでその方法� けを有効化することで強制できます。
の pull request で既定の [pull request のマージ] オプションをクリックすると、機能ブランチからのすべてのコミットがマージ コミット内でベース ブランチに追� されます。 pull request は、--no-ff オプションを使用してマージされます。
pull request をマージするには、リポジトリの書き込みアクセス許可が必要です。
デフォルトのマージ方法では、マージコミットが作成されます。 直線状のコミット履歴を強制して、保護されたブランチにマージコミットをプッシュできないようにすることができます。 詳細については、「保護されたブランチについて」を参照してく� さい。
マージコミットのsquash
の pull request で [スカッシュしてマージ] オプションを選択すると、その pull request のコミットは 1 つのコミットにスカッシュされます。 トピックブランチからコントリビュータの個々のコミットをすべて見る代わりに、コミットは１つのコミットにまとめられ、デフォルトブランチにマージされます。 スカッシュされたコミットを含む pull request は、早送りオプションを使用してマージされます。
pull request をスカッシュしてマージするには、リポジトリに書き込みアクセス許可が必要であり、リポジトリでスカッシュ マージが許可されている必要があります。
squashとマージは、よりス� ーズなGitの履歴をリポジトリに作り出すために利用できます。 作業途中でのコミットは、フィーチャブランチで作業しているときには役立ちますが、必ずしもGitの履歴に残すほど重要とはかぎりません。 デフォルトブランチへのマージに際してそれらのコミットを１つのコミットにsquashすれば、明快なGitの履歴と共にオリジナルの変更を残しておけます。
コミットの squash を有効化する前に、以下の� 点について考慮してく� さい:
- 特定の変更が元々いつ行われたのか、そして squash されたコミットを誰が作成したのかという情� �が失われます。
- squash してマージした後もプルリクエストの head ブランチで作業を続け、同じブランチ間に新しいプルリクエストを作成すると、以前 squash してマージしたコミットが新しいプルリクエストにリストされます。 また、連続するプルリクエストごとに繰り返し解決しなければならないコンフリクトが発生する� �合もあります。 詳細については、「pull request のマージについて」を参照してく� さい。
- "SHA" あるいは "hash" ID を使う Git コマンドの中には、オリジナルのコミット中の SHA ID が失われるので使うことが難しくなるものが生じるかもしれません。 たとえば、
git rerereを使用しても効果がないことがあります。
詳細については、「pull request にコミットのスカッシュを構成する」を参照してく� さい。
リベースとコミットのマージ
の pull request で [リベースしてマージ] オプションを選択すると、トピック ブランチ (またはヘッド ブランチ) からのすべてのコミットが、マージ コミットなしに個別にベース ブランチに追� されます。 このように、リベースとマージの動作は、線形プロジェクト履歴を維持することで、早送りマージ に似ています。 しかし、リベースは、ベース ブランチのコミット履歴を新しいコミットで書き直すことでこれを実現します。
GitHub Enterprise Server でのリベースとマージの動作は、git rebase とは少し異なっています。 GitHub でリベースしてマージすると、常にコミッター情� �が更新され、新しいコミット SHA が作成されますが、GitHub 外の git rebase は、先祖コミットの上でリベースが発生した� �合、コミッター情� �は変更されません。 git rebase の詳細については、Git ドキュメントの「git-rebase」を参照してく� さい。
pull request をリベースしてマージするには、リポジトリに書き込みアクセス許可が必要であり、リポジトリでリベース マージが許可されている必要があります。
git rebase の視覚的表現については、ProGit ブックの「GitBranching-Rebasing」の� を参照してく� さい。
コミットのリベースを有効化する前に、以下の� 点について考慮してく� さい:
-
リポジトリの共同作成者は、コマンド ライン上でリベースし、競合があれば解決し、変更を pull request のトピック ブランチ (あるいはリモートの head ブランチ) へフォース プッシュしなければ、 上で リベースとマージ のオプションを使えるようにならないかもしれません。 フォースプッシュは、コントリビューターが他者が作業のベースとしている作業を上書きすることがないよう、慎重に行わなければなりません。 リベースとマージ のオプションが で無効になる� �合や、それを再有効化するワークフローについては、「pull request のマージについて」を参照してく� さい。
-
pull request で Rebase と Merge オプションを使用する� �合は、ヘッド ブランチのコミットがコミット署名の検証なしでベース ブランチに追� されることに注意することが重要です。 このオプションを使用すると、元のコミットのデータとコンテンツを使用して、GitHub によって変更されたコミットが作成されます。 つまり、GitHub は、このコミットを本当に作成していないため、汎用システ� ユーザーとして署名することはできません。 GitHub では、コミッターの秘密署名キーにアクセスできないため、ユーザーの代わりにコミットに署名できません。
これを回避するには、ローカルでリベースとマージを行い、変更を pull request のベース ブランチにプッシュします。
詳細については、「pull request にコミットのリベースを構成する」を参照してく� さい。