gitのコマンドって、コマンド名だけでは動作が想像できないものが多いですよね…。けど、勉強していく中で呪いのように見かける言葉。
『rebaseすんなし』
ﾄﾞﾕｺﾄｰ？ってことでまとめ。
pull = fetch + merge（rebase）!
まず。
gitの主な動作はpush・fetch・merge・rebaseで出来ます。
| 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はブランチの根本の場所を変える・付け替える、です。