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

  • このエントリーをはてなブックマークに追加
fetchしてmerge or rebase

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を使うべきでない3つの理由

mergeするとどうなるの?

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


merge Fast-Forwardの場合
topicブランチは、master +(コミット)+(コミット)+(コミット) ということ。

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

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

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


merge 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するとどうなるの?

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


rebaseは付け替える
図のように、topicブランチが別のコミットに付け変わっています。これがrebase。
rebase前とrebase後では、内容は一緒でも違う点があります。
  • ①コミットID
  • ②1個前のコミット(親)
コミットには一個前のコミットIDの情報も含まれているのですが、rebaseすると、ブランチで枝分かれする根元のコミットが変わるので、前後では全く異なるコミットに変わってしまいます。
rebaseすると新しいコミットに生まれ変わる!

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

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

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

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

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

Comment

    • kairing

      分かりにくかったということで、すみません。。。

      rebaseできる時というのは、
      1)親となるコミットの内容は破棄しても問題ない(付け替えちゃうので、最新ファイルが上書きされちゃう)
      2)一人で開発してて、他の人がコミットすることがない

      開発しているのが自分一人だけなら、1だけ満たしてればいいけど、
      複数人でやってる時は、2を満たすために情報共有しておく必要がある・・・んだと思います。

      rebaseしちゃダメ!っていう理由が、
      他の人が修正中のファイルをrebaseしちゃうと、コミットできなくなっちゃう(修正が無駄になっちゃう)から…
      なんだと、いろんなサイトさんの見ていて思いました。
      私は一人で作業してるので、そういう場面に遭遇したことがないのであまり説得力はありませんが…;

      自分一人で作業しているなら、コミットIDとかが変わっちゃっても問題はないと思うので、
      Fast-Forward なマージの時も、rebaseして大丈夫・・・だと思います。

      初心者なりに噛み砕いた結果なので、何卒ご理解ください…>_<

      返信

Leave a Reply

  • (will not be published)

CAPTCHA