GitHubでのマージ3種類もあるの？どう使い分けるの？を解説してみた

この記事はAteam LifeDesign Advent Calendar 2023の12日目記事です。

はじめに

先日チーム内でこんな出来事がありました。

Sさん「PRたくさん作ってあるから、リリース用のPRにまとめておいて〜」
自分「はい！」

〜〜数時間後〜〜

自分「Sさん、リリース用のPRにまとめました！」
Sさん「これ、Squash and mergeしてない？ Rebase and mergeした方がコミット履歴が綺麗に残るから次は気をつけてね〜」
自分「、、、すいませんでした🙇」

Squash and mergeをしたことで、コミットが1つにまとまってしまい、コミットは綺麗になったものの、履歴がどのPRでどんな修正をしたのか、追いづらい状態になってしまいました。

反省の意も込めて、勉強した内容をアウトプットいたします。

GitHubでのマージの種類

上記でもチラッと記載していますが、GitHubでのマージの種類は以下3種類あります。

• Create a merge commit
• Squash and merge
• Rebase and merge

まずは、それぞれを言語化していきます。

Create a merge commit

• 動作でいうと、git merge --no-ffになる
• マージ先のブランチに、新たにマージコミットが作成される

Squash and merge

• 動作でいうと、git merge --squashになる
• マージ先のブランチに、新たにマージコミットが作成される
  • このマージコミットに、作業した複数のコミットが1つにまとめられる

Rebase and merge

• マージ先のブランチに、マージコミットは作成されない
• rebaseを行っているので、マージ先のコミットから、マージするブランチのコミットが続くようになる

次に、実際に操作した際の挙動を見てみようと思います。

挙動確認

Create a merge commit

前提

以下のようになっているコミットに対して、Create a merge commitを行います。

確認

test-1というブランチを切って、そこで以下のコミットを行いました。

• feat: test 1
• feat: test 2

PRを作成して、Create a merge commitを行ったところ、以下のようになりました。

作業したコミットと同時に、マージコミットも作成されていました。

Squash and merge

前提

上記の続きに、Squash and mergeを行います。

確認

test-2というブランチを切って、そこで以下のコミットを行いました。

• feat: test 3
• feat: test 4

PRを作成して、Squash and mergeを行ったところ、以下のようになりました。

マージコミットは作成されますが、作業したコミットもマージコミットに含められています。

Rebase and merge

前提

上記の続きに、Rebase and mergeを行います。

確認

test-3というブランチを切って、そこで以下のコミットを行いました。

• feat: test 5
• feat: test 6

PRを作成して、Rebase and mergeを行ったところ、以下のようになりました。

マージコミットは作成されず、続きとして反映されています。

使い方

結論、チームの開発スタイルや時と場合によって異なるので、一概にこうとは言えないと思います。

個人的には、Create a merge commitはマージコミットができてしまい、余分なコミットになってしまうので、あまり使うイメージはないです。
Squash and mergeとRebase and mergeを場面によって、使い分けると思います。

以下に、実際にあった例を記載いたします。

例

mainブランチから、作業ブランチとして、A・Bブランチを作成します。
その2つのブランチをまとめた、リリース用のCブランチも作成します。
最後に、リリース用のCブランチから作成したPRを、mainにマージします。

※ Bブランチは、ある理由でマージ後にリバートする予定です。

上記のような条件の場合、以下のような形になると思います。

• 作業ブランチA・Bを、リリース用Cブランチにマージする際は、それぞれSquash and merge
• リリース用Cブランチを、mainにマージする際は、Rebase and merge

図にすると、以下のようになります。

Bブランチはリバート前提なので、リリース用Cブランチには、コミットをまとめるSquash and mergeをして、mainへのマージは、Rebase and mergeにすると、後でリバートがしやすくなります。
mainへのマージを、Squash and mergeしてしまうと、Aブランチとコミットがまとまってしまうので、後でリバートがしにくくなってしまいます。

このように、時と場合によって、マージの方法を使い分ける必要があります。

まとめ

ここまでで、GitHubのマージ3種類と、どう使い分けるかを説明いたしました。
使い分けるかに関しては、本当に開発によると思うので、上記の例などを参考にその時に応じて、マージを使い分けていただけたらと思います。

最後までご覧いただき、ありがとうございました。

参考文献