今回はGitのrebaseについて書いていきたいと思います。
調べてみたら奥が深すぎたので、今回は本当に基本の基本だけ書いていきます。
はじめに
Gitで、あるブランチの変更を別のブランチに統合する方法が２つあります。
１つ目はmergeです。
mergeについてはこちら↓
Mergeの基本 [ Git ] - もとひろ blog
２つ目はrebaseです。
このrebaseについて説明していきます。
rebaseとは
Git - git-rebase Documentation
git-rebase - Reapply commits on top of another base tip
直訳すると、「別のベースチップの上にコミットを再適用します」となります。
分岐した作業履歴をひとつに統合するのがリベースです。
リベースを使うことで、自分のコミットした部分の履歴が１直線上になり、すっきりします。
リベースしたあとのマージはfast-forwardマージが行われます。
rebaseの例
マージの時と同じ図を使っていきます。
issueブランチで何らかの修正をしコミット２を作成後、mainブランチで別の修正をしコミット３を作成した状態です。
今回はすぐマージするのではなくリベースをしていきます。
issueブランチへ移動します。
$ git checkout issue
リベースを実行します。
$ git rebase main
コミット３でやった修正を取得し、コミット３の先に新しいマージコミット２’が作られました。
コミット２’には、コミット３に入っている修正（つまりmainブランチでやっていた修正）が含まれています。
あとはmainブランチに戻ってマージすればfast-forwardマージされます。
$ git checkout main $ git merge issue
コミット履歴が分岐せずきれいになりました。
rebaseの注意点
リベースする上でかなり重要な注意点があります。
プッシュしたコミットをリベースしてはいけない
ということです。
リベースすると既存のコミットを破棄して新たなマージコミットを作成します。
プッシュしたコミットをリベースしてしまうと、他の人は両方の歴史の流れを含むマージコミットを取得することになり、混乱のもとになってしまいます。
詳しい例はこちら↓
Git - リベース
ですので、リベースはプッシュ前のローカルリポジトリのコミット履歴をきれいにする際にだけ使いましょう。
push済みの変更をrebaseしてしまった場合
以下を参考にしてください。
Git - リベース
おわりに
私はまだrebaseを使った事がなかったので、自分で実際に操作してみてとても勉強になりました。
コミット履歴のきれいさは他の人が後々みたときにも大事になってきます。
今後はコミット履歴のきれいさも考えながら勉強していきたいと思いました。
参考リンク
おわります👋
