GitHub上でマージの仕方が3種類あることを知り、それぞれどういう状態になるのかというのを学んだのでまとめる。
3つのマージ
普段何気なくマージしてたけど、実は方法は3つあった。
それがこちら。
右のタブを押すと出現する。
普段はこの中の「create a merge commit」をやっていた。
マージ後の状態
ではそれぞれの方法でマージした後、一体どうなるのか。
説明するより図で見た方がきっと早い。
ということで作図した。
まず、状態の確認から。
masterからブランチを切ってY, Zとコミットが作られている。
その間にmasterはXというコミットが作られている。
コンフリクトはないものとする。
Create a merge commit
これがデフォルトで設定されているためよく見慣れている。
この場合、マージされた際にマージコミットMが生成される。
元のブランチの状態も全て残る。
この時のコミットメッセージはデフォルトだと「Merge pull request #{PR番号} from {ブランチ名}」となる。
元のブランチの状態もコミットログも全て残す正直者。
Squash and merge
この場合、マージコミットMは同様に生成されるものの、ブランチのそれまでの複数のコミットは一つのマージコミットにまとめられる。
かつ、元のブランチの情報は残らない。
マージコミットのコミットメッセージはデフォルトだと「{PRタイトル} (#{PR番号})」となる。
元のブランチの状態は残さないが、コミットを一つにまとめるまとめ上手。
Rebase and merge
この場合、マージコミットは生成されない。
かつ、元のブランチの情報も残らない。
ブランチで作業していたにも関わらず、
あたかも「最初から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は色んな使い方があるからちょっとずつ覚えていきたい。