【git】分かりやすく！mergeは「合流」、rebaseは「付け替え」!

gitのコマンドって、コマンド名だけでは動作が想像できないものが多いですよね…。けど、勉強していく中で呪いのように見かける言葉。
『rebaseすんなし』
ﾄﾞﾕｺﾄｰ？ってことでまとめ。

pull = fetch　+　merge（rebase）!

まず。
gitの主な動作はpush・fetch・merge・rebaseで出来ます。

pullはー？っていうと、fetch して mergeする = pull。
ちなみに、fetch して rebase する = pull --rebase。

要するに、pullは使わなくてOK！ってことです。
使わなくていい理由はこちらの記事が分かりやすかったです。ご参照ください。
Git pullを使うべきでない３つの理由

mergeするとどうなるの？

mergeは2種類ある！その1・・・Fast-Forward

topicブランチは、master +（コミット）+（コミット）+（コミット）　ということ。

マージするってことは・・・、masterブランチに、（コミット）+（コミット）+（コミット）を足すということ。

ということは、topic = master　なので、topicまで進めちゃえー！っていうのが、Fast-Forward = 早送りなマージ。

mergeは2種類ある！その2・・・Non Fast-Forward

masterにコミットがされて、ブランチが完全に枝分かれした状態なので、topic = masterではないので、Fast-Forwardは出来ません。

なので、
master +（コミット）+（コミット）+（コミット）= 〇（マージコミット）
マージした履歴を残します（〇というマージコミットを作ります）。
マージコミットを作るときに、コンフリクトがあればもちろんエラーが出ます。コンフリクト解消後に、マージコミットができます。

Fast-ForwardとNon Fast-Forwardの違いは？

ずばり、マージしたというコミットが残るか残らないか、です。
早送りできる状態でもマージコミットを残す時は、
git merge —no-ff topicとすればOK。

一人で開発していて、何でも履歴を残しておきたいならgit merge —no-ff。
一人で開発していて、すぐに修正終わっちゃってブランチにする必要がなかったな…(´・ω・`)なんて時はgit merge。

rebaseするとどうなるの？

一言でいうと、「付け替える」「場所を変える」

図のように、topicブランチが別のコミットに付け変わっています。これがrebase。
rebase前とrebase後では、内容は一緒でも違う点があります。

• ①コミットID
• ②1個前のコミット（親）

コミットには一個前のコミットIDの情報も含まれているのですが、rebaseすると、ブランチで枝分かれする根元のコミットが変わるので、前後では全く異なるコミットに変わってしまいます。

コミットIDが変わっちゃう＝全く新しいコミットになる。だからrebaseしちゃダメ！

リモートにpush済みのコミットを、rebaseで新しいコミットにしてしまった場合。
他の人がリモートを更新して別のコミットをpushした場合、もうrebaseしたコミットはpushできません。
強制的にpushすることは可能ですが、そうするとコミットログがおかしなことになり、今度は他の人がプルできなくなるということになり、迷惑のループとなります（苦笑）。
コミットIDが変わっちゃうからpushできなくなる場合がある。だからrebaseすんなし、ということですね。

まとめ！mergeとrebaseの違いはココ！

mergeはブランチを合流させる。rebaseはブランチを付け替える。

mergeもFast-ForwardとNon Fast-Forwardで、マージコミットを残す残さないの違いがありますが、
mergeはブランチを合流、rebaseはブランチの根本の場所を変える・付け替える、です。