リベースとは
ブランチの基点となるコミット（親コミット）を、別のコミットに移動すること。
コミットの履歴を一直線にしつつ、他のブランチの変更分を取り込む。
リベースの使い方
【例】masterブランチにfeatureブランチを取り込みたい場合。
- 通常のmergeならば
//masterブランチにいる状態でmergeする
$ git merge feature
- rebaseを使ってからmergeするならば
//まずはfeatureブランチに移動する
$ git checkout feature
//featureブランチにいる状態でrebaseする
$ git rebase master
//ここでmasterブランチに切り替えて
$ git checkout master
//masterブランチにいる状態でmergeする
$ git merge feature
rebaseを行ってからmergeを行うとファストフォワードが起こり、mergeコミットは発生しない。
リベースでのNG
GitHubにプッシュしたコミットをリベースするのは絶対にNG。
プッシュしたコミットをリベースして、それをまたプッシュしようとすると、プッシュ出来ないようになっている。
$ git push -fで強制的にプッシュすると、Gitの履歴が完全に壊れてしまうので、行ってはいけない。
マージとリベースの比較
マージ
- メリット…コンフリクトが1回しか生じない。
- デメリット…マージコミットがたくさんあると、履歴が複雑化する。
リベース
- メリット…履歴を綺麗に（一直線に）保つことができる。
- デメリット…コミットそれぞれに、コンフリクトの解消が必要。
使い分けのコツ
プッシュしていないローカルの変更にはリベースを使い、プッシュした後はマージを使う。
コンフリクトしそうならマージを使う。
またPush前にコミットをきれいに整えたり、コミットメッセージを書き換えたいときには、リベースが使える。
※GitHubにPushしていないコミットはリベースしてはいけない。
リベースで変更履歴を変更する
直前のコミットをやり直す
今のステージの状態で、コミットを上書きする。
//コミットしたい内容で、git addを済ませておく
$ git commit --amend
//commitした時のコミットメッセージが立ち上がり、書き直すことができる
複数のコミットをやり直す
$ git rebase -i コミットiD
//直前3つのコミットをやり直す
$ git rebase -i HEAD~3
コミットを修正する手順
- 上記コマンドを実行し、対話的リベースモードに入る。するとエディタが立ち上がり、
pick コミットiD コミットメッセージの情報が指定した件数表示される。 - 修正したいコミットの
pickという文字をeditと書き直し、コミットエディタを閉じる。 - editのコミットの内容を修正できるようになっているので、ローカルでファイルを編集し、
git addしたうえで、git commit --amendを実行する。 -
git rebase --continueコマンドを実行して、リベースを完了する。 ※この際、pickのコミットはそのままのコミット内容を適用して次へ進む。
コミットの指定方法
HEAD
最新のコミットのこと。HEAD~
最新のコミットの親コミットを指定する。HEAD~数字
HEADを基点にして、数値分の親コミットまで指定する。HEAD^（数字）
マージした場合の親を指定する。
数字については同上。