🚀

今更ながらGit rebaseの挙動をちゃんと理解して使えるようになる試み

に公開
2件
Git
tech

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 ユーザーはぜひご参加ください！！

https://serverside-kt.connpass.com/

また関西在住のソフトウェア開発者を中心に、関西エンジニアコミュニティを一緒に盛り上げてくださる方を募集しています。

よろしければ Conpass からメンバー登録よろしくお願いいたします。

https://blessingsoftware.connpass.com/

Discussion

chocochoco

rebase はコミットが改変されるので、取り返しのつかないことになってしまうかも

ご存知かもしれないですが rebase での操作を間違えた（e.g. コンフリクトの解消に誤りがあった）ときでも reflog を使って rebase 前に戻せる可能性があります。ただ reflog も万能ではなく、

  • commit されていないものは記録されない（= 復元できない）
  • デフォルトでは保存期間が 90 日なので、90 日以前に戻せない場合がある（90 日以上戻すことはあまりないと思いますが...）

といった制約があります。直近に commit されたものであれば大抵復元はできるので困ったら reflog があることを思い出すと役立つかもしれません。

参考

2
KanonKanon

補足コメントありがとうございます！！
恥ずかしながらreflogを知らなかったので勉強になりました🙏

1