GitHubでの3種類のマージの仕方

公開日: 2020/06/02最終更新日: 2021/06/12

GitHub上でマージの仕方が3種類あることを知り、それぞれどういう状態になるのかというのを学んだのでまとめる。

3つのマージ

普段何気なくマージしてたけど、実は方法は3つあった。
それがこちら。
右のタブを押すと出現する。

普段はこの中の「create a merge commit」をやっていた。

ではそれぞれの方法でマージした後、一体どうなるのか。

説明するより図で見た方がきっと早い。
ということで作図した。

まず、状態の確認から。
masterからブランチを切ってY, Zとコミットが作られている。
その間にmasterはXというコミットが作られている。
コンフリクトはないものとする。

これがデフォルトで設定されているためよく見慣れている。
この場合、マージされた際にマージコミットMが生成される。
元のブランチの状態も全て残る。

この時のコミットメッセージはデフォルトだと「Merge pull request #{PR番号} from {ブランチ名}」となる。

元のブランチの状態もコミットログも全て残す正直者。

この場合、マージコミットMは同様に生成されるものの、ブランチのそれまでの複数のコミットは一つのマージコミットにまとめられる。
かつ、元のブランチの情報は残らない。

マージコミットのコミットメッセージはデフォルトだと「{PRタイトル} (#{PR番号})」となる。

元のブランチの状態は残さないが、コミットを一つにまとめるまとめ上手。

この場合、マージコミットは生成されない。
かつ、元のブランチの情報も残らない。

ブランチで作業していたにも関わらず、
あたかも「最初からmasterでコミットし続けてましたよ？」
と見えるような一番しれっとしたマージ方法。

元のブランチの状態は残さず、手柄を全て自分の物にするかのようなあくどいやつ。(あくまで個人のイメージです。)

GitHubの「Settings > Options」から3種類のうち、どれを表示させられるか設定できる。

これで間違って別の方法でマージしちゃった。。。ということが無くなる。

元のブランチの状態を見たいなら「create a merge commit」一択。
元のブランチの情報が必要ないのなら、あとはコミットログを残すかどうかで
「Squash and merge」か「Rebase and merge」を決めるという感じかな。

ただ、結局のところチームで方針決めてそれに従うことになる。

個人的にはデフォルトのcreate a merge commitが一番好きだ。
ただこいつの弱点は、チーム開発でそれぞれがブランチ切ったりしてるとmasterブランチがかなり見づらくなること。

ちなみにうちのチームでは「Squash and merge」を採用している。
masterの状態が常に1プルリクに対して1コミットとなるのでこれが一番masterの状態がスッキリする。

個人的には「Rebase and merge」がいまいちメリットが分からない。。
masterのコミットの状態がどんどん増えるのに、情報少なくなるだけな気がする。。

ここは結構人によって好き好みが分かれる。
実際うちの開発チームでもブランチ情報残したい派とmasterスッキリさせたい派が半々くらいだった。
宗教戦争にならないように注意が必要。

Gitは色んな使い方があるからちょっとずつ覚えていきたい。