結論
git merge の代わりに使いましょう！
序章
本記事では、rebase初心者の「rebaseってどこでどう使えば良いんだ🤔」という疑問に答えていきます。
rebaseは超汎用的なコマンドなので
Gitマスターの皆さんには物足りないかと思いますが、ご了承ください。🙇
詳しい説明
git rebaseとは
解説記事です。
要はブランチの歴史改ざんコマンドです。
git mergeとは
解説記事です。
要はブランチとブランチを統合するコマンドです。
なんでわざわざrebase使うの？
前提条件
今親ブランチmasterと子ブランチdevelopがあるとします。
画像の数字は時系列順でのコミット順番です。
時系列が master → develop → master になっているのがわかると思います。
masterブランチ
developブランチ
コミットログが汚くなる
git mergeは超強力なブランチ合体コマンドですが、
コミットログがぐちゃぐちゃになっていく、という問題があります。
要素１：作業ブランチの持つコミットの間に他ブランチのコミットが挟まる
これはdevelop から $ git merge master を実行した結果です。
developコミットの間にmasterブランチのコミットが来ていますね。
git mergeだとコミットを時系列順に並べて合体させるので仕方ないのですが、
なんとなくdevelopのコミットはまとまって表示されてほしくはないですか？
要素２：mergeメッセージが生成される
上画像の一番上にcommitした覚えのないコミットがあります。
これはmergeした時必ず生成されるコミットです。
mergeするたび生成されるため、結構な頻度で入ってきます。
レビュアーやコーダーがコミットの履歴を追う際には一切必要ないですよね？
なるべく減らしたくはないですか？
だからrebaseを使おう！
ここで、mergeではなく**$ git rebase master**を実行した場合の結果を見てみると・・・
コミットがまとまる
画像のように、masterブランチのコミットが下に行き、
developのコミットがすべて上に配置されるようになりました。綺麗ですね！🔅
マージコミットが出来ない
git mergeのときは生成されていたマージコミットがありません！美しい・・・
使ってはいけないrebase
こんなに美しいコミットログを生成するrebaseですが、使ってはいけないシーンが存在します。
それは複数人が参照しているブランチに変更を取り込む場合です。
下は某ページの画像を拝借したものですが、
開発ブランチ(develop)から機能開発ブランチ(feature)が2つ切られています。
このようなブランチ構造でrebaseをして良いのは各featureブランチのみです！
developブランチでは複数のfeatureブランチに参照されているため、
rebaseを控えたほうが懸命です。
なんで使っちゃいけないの？
自分より詳しく説明しているサイトがたくさんあります！
例えばこのサイトとか。
簡単に言うと、rebaseは歴史を作り変える処理です。
なのでfeatureブランチがdevelopの古い歴史に
依存しているときにdevelopの歴史を全く違うものにした場合、
次にfeatureブランチをdevelopブランチに取り込むとコンフリクトの雨あられになります。😭
じゃあどこで使うべき？
機能追加や修正等、
自分がリポジトリでなにか作業をする場合は必ずブランチを切りますよね？
このような1人しか見ていない、参照していないブランチにrebaseを使ってやると良いです。
例えば自分の作業ブランチはrebaseを使うようにすることで、
小さくきれいなコミットを作ることが出来、かつマージコミットを量産せずに済みます。
じゃあrebaseはmergeのときだけ使えば良いんだね！
実は、rebaseの本当の意味はgitの歴史を書き換えるコマンドであり、
イコールmergeの代用なわけではありません。
rebaseはそれ以上の可能性を持っているので、ぜひ他の使い所を見つけてみてください。
結論
というわけでrebaseは自分ひとりが参照しているような末端のブランチで行いましょう！
masterやdevelopなど、複数のコーダが参照するブランチにはmergeで対処しましょう！
良いGitライフを〜😘