Skip to main content
ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

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

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

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

Note: When using the merge queue, you no longer get to choose the merge method, as this is controlled by the queue. For information about merge queue, see "Managing a merge queue."

GitHub.com上のプルリクエストでデフォルトのMerge pull request(プルリクエストのマージ)オプションをクリックすると、フィーチャブランチからのすべてのコミットがマージコミット内でベースブランチに追加されます。 プルリクエストは、--no-ffオプションを使ってマージされます。

プルリクエストをマージするためには、リポジトリの書き込み権限を持っていなければなりません。

standard-merge-commit-diagram

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

マージコミットのsquash

GitHub.com上のプルリクエストでSquash and merge(squashとマージ)オプションを選択すると、そのプルリクエストのコミットは1つのコミットにsquashされます。 トピックブランチからコントリビュータの個々のコミットをすべて見る代わりに、コミットは1つのコミットにまとめられ、デフォルトブランチにマージされます。 squashされたコミットを持つプルリクエストは、fast-forwardオプションを使ってマージされます。

プルリクエストをsquashしてマージするには、リポジトリへの書き込み権限を持っていなければならず、リポジトリではsquashマージが許可されていなければなりません。

commit-squashing-diagram

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

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

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

詳しい情報についてはプルリクエストのためのコミットsquashingの設定を参照してください。

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

GitHub.com上のプルリクエストでRebase and merge(リベースとマージ)オプションを選択すると、トピックブランチ(あるいはheadブランチ)のすべてのコミットが、マージコミットなしに個別にベースブランチに追加されます。 In that way, the rebase and merge behavior resembles a fast-forward merge by maintaining a linear project history. However, rebasing achieves this by re-writing the commit history on the base branch with new commits.

GitHub Enterprise Cloud上でのリベースとマージの振る舞いは、gitのリベースとは少し異なっています。 GitHub上でのリベースとマージは、常にコミッターの情報を更新し、新しいSHAを生成しますが、GitHub外でのgit rebaseは祖先のコミット上でリベースが生じたときにコミッター情報を変更しません。 For more information about git rebase, see git-rebase in the Git documentation.

プルリクエストをリベースしてマージするには、リポジトリへの書き込み権限が必要で、リポジトリではリベースマージが許可されていなければなりません。

git rebaseの視覚的な表現については、書籍Pro Gitの"Git Branching - Rebasing"の章を参照してください。

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

  • リポジトリのコントリビューターは、コマンドライン上でリベースし、コンフリクトがあれば解決し、変更をプルリクエストのトピックブランチ (あるいはリモートの head ブランチ) へフォースプッシュしなければ、GitHub.com 上でリベースとマージという選択肢を使えるようにならないかもしれません。 フォースプッシュは、コントリビューターが他者が作業のベースとしている作業を上書きすることがないよう、慎重に行わなければなりません。 GitHub.comでリベースとマージの選択肢が無効化されている場合と、それを再度有効にするワークフローについてもっと知るには、プルリクエストのマージについてを参照してください。

  • When using the Rebase and Merge option on a pull request, it's important to note that the commits in the head branch are added to the base branch without commit signature verification. When you use this option, GitHub creates a modified commit, using the data and content of the original commit. This means that GitHub didn't truly create this commit, and can't therefore sign it as a generic system user. GitHub doesn't have access to the committer's private signing keys, so it can't sign the commit on the user's behalf.

    A workaround for this is to rebase and merge locally, and then push the changes to the pull request's base branch.

詳しい情報についてはプルリクエストのためのコミットのリベースの設定を参照してください。