GitHub上でマージの仕方が3種類あることを知り、それぞれどういう状態になるのかというのを学んだのでまとめる。
3つのマージ
普段何気なくマージしてたけど、実は方法は3つあった。
それがこちら。
右のタブを押すと出現する。
![f:id:suna_tech:20200531171628p:plain マージの方法3種類](https://cdn-ak.f.st-hatena.com/images/fotolife/s/suna_tech/20200531/20200531171628.png)
普段はこの中の「create a merge commit」をやっていた。
マージ後の状態
ではそれぞれの方法でマージした後、一体どうなるのか。
説明するより図で見た方がきっと早い。
ということで作図した。
![f:id:suna_tech:20200531171918j:plain マージ後の状態](https://cdn-ak.f.st-hatena.com/images/fotolife/s/suna_tech/20200531/20200531171918.jpg)
まず、状態の確認から。
masterからブランチを切ってY, Zとコミットが作られている。
その間にmasterはXというコミットが作られている。
コンフリクトはないものとする。
Create a merge commit
これがデフォルトで設定されているためよく見慣れている。
この場合、マージされた際にマージコミットMが生成される。
元のブランチの状態も全て残る。
この時のコミットメッセージはデフォルトだと「Merge pull request #{PR番号} from {ブランチ名}」となる。
![f:id:suna_tech:20200531172611j:plain Create a merge commit](https://cdn-ak.f.st-hatena.com/images/fotolife/s/suna_tech/20200531/20200531172611.jpg)
元のブランチの状態もコミットログも全て残す正直者。
Squash and merge
この場合、マージコミットMは同様に生成されるものの、ブランチのそれまでの複数のコミットは一つのマージコミットにまとめられる。
かつ、元のブランチの情報は残らない。
マージコミットのコミットメッセージはデフォルトだと「{PRタイトル} (#{PR番号})」となる。
![f:id:suna_tech:20200531173008j:plain Squash and merge](https://cdn-ak.f.st-hatena.com/images/fotolife/s/suna_tech/20200531/20200531173008.jpg)
元のブランチの状態は残さないが、コミットを一つにまとめるまとめ上手。
Rebase and merge
この場合、マージコミットは生成されない。
かつ、元のブランチの情報も残らない。
ブランチで作業していたにも関わらず、
あたかも「最初からmasterでコミットし続けてましたよ?」
と見えるような一番しれっとしたマージ方法。
![f:id:suna_tech:20200531173852j:plain Rebase and merge](https://cdn-ak.f.st-hatena.com/images/fotolife/s/suna_tech/20200531/20200531173852.jpg)
元のブランチの状態は残さず、手柄を全て自分の物にするかのようなあくどいやつ。(あくまで個人のイメージです。)
設定で表示を変えられる
GitHubの「Settings > Options」から3種類のうち、どれを表示させられるか設定できる。
![f:id:suna_tech:20200531221242p:plain Merge方法設定](https://cdn-ak.f.st-hatena.com/images/fotolife/s/suna_tech/20200531/20200531221242.png)
これで間違って別の方法でマージしちゃった。。。ということが無くなる。
どう使い分けるの?
元のブランチの状態を見たいなら「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は色んな使い方があるからちょっとずつ覚えていきたい。