◾️はじめに
マージでトラブルがあったので、Merge周辺のことを調べてみた
目次
【０】前提知識 １）Squash ２）Rebase 【１】Github の PR のマージ方法 １）Create a merge commit ２）Squash and merge ３）Rebase and merge 【２】メリット・デメリット １）Create a merge commit ２）Squash and merge ３）Rebase and merge 【３】Github上でのマージ方法に関する設定あれこれ １）マージ方法の強制/許可/無効化 ２）ブランチごとでの設定 【４】補足：Githubのブランチ履歴調査
【０】前提知識
１）Squash
* 複数のコミットを1つのコミットにまとめる操作 cf. Squash (スクウォッシュ?スカッシュ?) = 押しつぶす。（名） カボチャ、スカッシュ
２）Rebase
* 別ブランチの内容をブランチの後ろに付け替える操作 => 指定したコミットを、ブランチを変えて作り直す操作 cf. rebase (リベース) = 付け替え => 詳細は以下の関連記事を参照の事
Git ～ 基本編 / マージ・リベース ～
https://dk521123.hatenablog.com/entry/2019/06/10/200917
【１】Github の PR のマージ方法
* Github の Pull request (PR) のマージは、以下の3種類。 １）Create a merge commit ２）Squash and merge ３）Rebase and merge
１）Create a merge commit
* マージコミットを作成して、マージ => マージコミットのイメージは、以下の公式ドキュメント参照
Gitコマンド
# Non Fast-Forward マージ git merge --no-ff
２）Squash and merge
* PRに含まれるコミットを1つにまとめる。 * その後、そのコミットをマージ先のbaseブランチへマージ => Squashのイメージは、以下の公式ドキュメント参照
Gitコマンド
# Squash マージ git merge --squash
３）Rebase and merge
* PRに含まれるコミットをマージ先ブランチに追加 * このとき、マージコミットは作られず、コミットが個々に追加
Gitコマンド
# Fast-Forward マージ git merge --ff-only
【２】メリット・デメリット
１）Create a merge commit
メリット
* マージコミットができるので、Revert しやすい * すべてのコミットログが残るため、コードの意図の調査をしやすい
デメリット
* マージコミットが大量に発生する
一口メモ
* 「すべてのコミットログが残る」はメリットであり、 デメリット「マージコミットが大量に発生する」でもある
２）Squash and merge
メリット
* マージコミットができるので、 Revert しやすい * 単一コミットにまとめられるので、コミットログがシンプルになる
デメリット
* 詳細なコミット履歴が失われる * コンフリクトが発生する場合がある => 詳細は、以下のサイトを参照のこと
https://tech.mobilefactory.jp/entry/2023/11/29/160000
３）Rebase and merge
メリット
* 履歴が単純になる
デメリット
* 元のコミットから変更内容が変更される * rebaseはコミットが改変されてしまうため、 元に戻せなくなるかも、、、 * コンフリクトが発生した場合、複数回コンフリクト解消をしなければならない
https://www.zoma-blog.com/post/other/git/20230222_git_rebase_avoid/
https://zenn.dev/yumiyoshi/scraps/37723d020d4541
【３】Github上でのマージ方法に関する設定あれこれ
１）マージ方法の強制/許可/無効化
* 以下に記載されている
より抜粋 ~~~~~ リポジトリでの GitHub.com 上のすべての pull request のマージに対する コミットのスカッシュを、強制、許可、または無効化できます ~~~~~ # Squash だけでなく３種類の方法を設定でコントロールできる
Github の 各種設定 ～ 入門編 ～
https://dk521123.hatenablog.com/entry/2024/07/11/131849
の「【１】Pull-Request」の以下の項目で管理。
| Rules | Explanations | Default | Memo |
|---|---|---|---|
| Allow merge commits | マージコミット許容 | Yes | |
| Allow squash merging | スカッシュマージ許容 | Yes | |
| Allow rebase merging | リベースマージ許容 | Yes |
２）ブランチごとでの設定
* マージコミットの禁止（Squash・Rebaseの強制）であれば、 以下の関連記事の「Require linear history」で可能
Github の 各種設定 ～ 入門編 ～
https://dk521123.hatenablog.com/entry/2024/07/11/131849
Require linear history
https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-linear-history
直線状のコミット履歴を強制すると、 コラボレータがブランチにマージコミットをプッシュすることを防げます。 つまり、保護されたブランチにマージされたプルリクエストは、 squash マージまたはリベースマージを使用する必要があります。
【４】補足：Githubのブランチ履歴調査
* 以下でグラフィカルに確認できる https://github.com/<GithubAccount>/<RepositoryName>/network
関連記事
Git ～ 入門編 ～
https://dk521123.hatenablog.com/entry/2018/06/29/104028
Git ～ 基本編 / マージ・リベース ～
https://dk521123.hatenablog.com/entry/2019/06/10/200917
Github ～ 入門編 ～
https://dk521123.hatenablog.com/entry/2019/07/18/234652
Github ～ Milestone ～
https://dk521123.hatenablog.com/entry/2025/04/20/233920
Github の 各種設定 ～ 入門編 ～
https://dk521123.hatenablog.com/entry/2024/07/11/131849
