TL;DR
最近チーム内で、mergeではなくrebaseを推奨する動きが出てきたので、この機会に rebase の動きをちゃんと理解しておこうという足跡です。
merge の動きを確認する
まず、merge_aというブランチを作成し、一つコミットを作ります。
次にmerge_bというブランチを作成し、一つコミットを作ります。
再びmerge_aブランチに戻り、一つコミットを作ります。
ここで、merge_aにmerge_bをマージします。
すると以上のようにマージコミットが作成され、コミットの時系列の順にブランチが並びました。
rebase の動きを確認する
まず、rebase_aというブランチを作成し、一つコミットを作ります。
次にrebase_bというブランチを作成し、一つコミットを作ります。
再びrebase_aブランチに戻り、一つコミットを作ります。
ここで b をベースにリベースすると…？
するとマージとは異なりマージコミットは作成されず、rebase_bの履歴の続きにrebase_aの変更が続く形のコミット履歴が出来上がりました。
以上からわかる rebase のいいところ
- コミット履歴が常に 1 本になり、**誰がいつどのタイミングでどのファイルに変更をいれたか？**を追うことが容易になる
- 同じことですがブランチが枝分かれしないため、変更履歴が見やすい
rebase のリスク
- コミットが改変される
- マージはコミットが追加されるだけなので、失敗しても
resetで戻せる - rebase はコミットが改変されるので、取り返しのつかないことになってしまうかも
- マージはコミットが追加されるだけなので、失敗しても
- rebase した後は force-push が必要
- リモートブランチと履歴が変わってしまうため、
git push --force-with-leaseによりローカル側の変更を反映する必要があります
- リモートブランチと履歴が変わってしまうため、
おわりに
メンバー募集中！
サーバーサイド Kotlin コミュニティを作りました！
Kotlin ユーザーはぜひご参加ください！！
また関西在住のソフトウェア開発者を中心に、関西エンジニアコミュニティを一緒に盛り上げてくださる方を募集しています。
よろしければ Conpass からメンバー登録よろしくお願いいたします。
Discussion
ご存知かもしれないですが rebase での操作を間違えた（e.g. コンフリクトの解消に誤りがあった）ときでも reflog を使って rebase 前に戻せる可能性があります。ただ reflog も万能ではなく、
といった制約があります。直近に commit されたものであれば大抵復元はできるので困ったら reflog があることを思い出すと役立つかもしれません。
参考
補足コメントありがとうございます！！
恥ずかしながらreflogを知らなかったので勉強になりました🙏