Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-09-28. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

GitHub上のマージ方法について

この記事では、次の項目が扱われます。

リポジトリへのプッシュアクセスを持つコントリビューターに対し、your GitHub Enterprise Server instance上でプルリクエストを様々なマージオプションでマージすることを許可するか、リポジトリへのすべてのプルリクエストに特定のマージ方法を強制することができます。

your GitHub Enterprise Server instance 上でプルリクエストのマージオプションを設定して、ワークフローの要求と Git の履歴管理への要望を満たすことができます。 詳細については、「pull request マージの構成」を参照してください。コミットsquashingあるいはリベースのようなマージの1つの種類を、リポジトリでその方法だけを有効化することで強制できます。

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

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

standard-merge-commit-diagram

デフォルトのマージ方法では、マージコミットが作成されます。 直線状のコミット履歴を強制して、保護されたブランチにマージコミットをプッシュできないようにすることができます。 詳細については、「保護されたブランチについて」を参照してください。

マージコミットのsquash

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 を有効化する前に、以下の欠点について考慮してください:

  • 特定の変更が元々いつ行われたのか、そして squash されたコミットを誰が作成したのかという情報が失われます。
  • squash してマージした後もプルリクエストの head ブランチで作業を続け、同じブランチ間に新しいプルリクエストを作成すると、以前 squash してマージしたコミットが新しいプルリクエストにリストされます。 また、連続するプルリクエストごとに繰り返し解決しなければならないコンフリクトが発生する場合もあります。 詳細については、「pull request のマージについて」を参照してください。
  • "SHA" あるいは "hash" ID を使う Git コマンドの中には、オリジナルのコミット中の SHA ID が失われるので使うことが難しくなるものが生じるかもしれません。 たとえば、git rerere を使用しても効果がないことがあります。

詳細については、「pull request にコミットのスカッシュを構成する」を参照してください。

リベースとコミットのマージ

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」の章を参照してください。

コミットのリベースを有効化する前に、以下の欠点について考慮してください:

  • リポジトリの共同作成者は、コマンド ライン上でリベースし、競合があれば解決し、変更を pull request のトピック ブランチ (あるいはリモートの head ブランチ) へフォース プッシュしなければ、your GitHub Enterprise Server instance 上で リベースとマージ のオプションを使えるようにならないかもしれません。 フォースプッシュは、コントリビューターが他者が作業のベースとしている作業を上書きすることがないよう、慎重に行わなければなりません。 リベースとマージ のオプションが your GitHub Enterprise Server instance で無効になる場合や、それを再有効化するワークフローについては、「pull request のマージについて」を参照してください。

  • pull request で Rebase と Merge オプションを使用する場合は、ヘッド ブランチのコミットがコミット署名の検証なしでベース ブランチに追加されることに注意することが重要です。 このオプションを使用すると、元のコミットのデータとコンテンツを使用して、GitHub によって変更されたコミットが作成されます。 つまり、GitHub は、このコミットを本当に作成していないため、汎用システム ユーザーとして署名することはできません。 GitHub では、コミッターの秘密署名キーにアクセスできないため、ユーザーの代わりにコミットに署名できません。

    これを回避するには、ローカルでリベースとマージを行い、変更を pull request のベース ブランチにプッシュします。

詳細については、「pull request にコミットのリベースを構成する」を参照してください。