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

ここには以下の内容があります:

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

You can configure pull request merge options on 使用している GitHub Enterprise Serverインスタンス to meet your workflow needs and preferences for managing Git history. For more information, see "Configuring pull request merges." コミットsquashingあるいはリベースのようなマージの1つの種類を、リポジトリでその方法だけを有効化することで強制できます。

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

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

マージコミットのsquash

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

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

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

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

• 特定の変更が元々いつ行われたのか、そして squash されたコミットを誰が作成したのかという情報が失われます。
• "SHA" あるいは "hash" ID を使う Git コマンドの中には、オリジナルのコミット中の SHA ID が失われるので使うことが難しくなるものが生じるかもしれません。 たとえばgit rerereはそれほど効果的ではなくなるかもしれません。

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

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

使用している GitHub Enterprise Serverインスタンス上のプルリクエストでRebase and merge（リベースとマージ）オプションを選択すると、トピックブランチ（あるいはheadブランチ）のすべてのコミットが、マージコミットなしに個別にベースブランチに追加されます。 リベースされたコミットを持つプルリクエストは、fast-forwardオプションを使ってマージされます。

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

GitHub Enterprise上でのリベースとマージの振る舞いは、gitのリベースとは少し異なっています。 GitHub上でのリベースとマージは、常にコミッターの情報を更新し、新しいSHAを生成しますが、GitHub外でのgit rebaseは祖先のコミット上でリベースが生じたときにコミッター情報を変更しません。 git rebaseに関する詳しい情報については書籍Pro Gitの"Git rebase" の章を参照してください。

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

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

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

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