一回で完璧なコードが書けると思わせ、パッチのレビューやマージを容易にします。
バージョン管理を使って定期的に作業の痕跡を残し、レビューのために何かをコミットする準備ができたら、プライベートな下書きの作業をすべて隠して、ただひとつの完璧なパッチをコミットすることができたら素晴らしいと思いませんか? git rebase -i は、あなたの履歴を書き換えて、誰もがあなたが一度に完璧なコードを書いたと思うようにする完璧な方法です！
git rebase は何をするのですか?
Gitの複雑な仕組みに詳しくない方のために、簡単に紹介しましょう。この識別子は、親バージョンの一意識別子と新バージョンの親バージョンとの差分をハッシュしたものです。これによってリビジョンツリーが作成され、プロジェクトをチェックアウトしたすべての人が自分のコピーを取得します。さまざまな人がさまざまな方向にプロジェクトを進めることができ、それぞれが異なる分岐点から始めることができます。
ひとつは merge: git merge を使う方法、もうひとつは rebase: git rebase を使う方法です。
git merge を使用すると、master ブランチのすべての変更とローカルのすべての変更をマージした新しいコミットが作成されます。コンフリクトがあればフラグが立てられ、マージコミットをローカルリポジトリにコミットする前にそれを解決することができます。変更を親リポジトリにプッシュしなおすと、ローカルのすべての作業がブランチとして Git リポジトリに反映されます。
しかし、git のリベースの仕組みは異なります。git rebase はコミットをロールバックし、master ブランチの先頭から再度コミットを行います。この結果、大きな変化がふたつ起こります。まず、コミットが別の親ブランチからブランチされるようになったため、そのハッシュが再計算されます。そして、リポジトリをクローンした人がそのリポジトリの壊れたコピーを取得する可能性があります。第二に、「マージコミット」がないため、master ブランチに変更を再分岐したときにマージの衝突が認識されます。これで、変更をプッシュしてもブランチには変更が反映されず、master ブランチの最新コミットですべての変更を行ったように見えます。
しかし、どちらの方法にも欠点があります。コードを共有する準備が整うころには、ローカルで問題に取り組んでいたときの落書きや編集がみんなに見えてしまうことです。そこで登場するのが git rebase の --interactive フラグです。
git rebase -i register
git rebase の素晴らしいところは、履歴を書き換えてくれることです。しかし、なぜ後の時点からブランチアウトしたことにしてしまうのでしょうか?git rebase -i は対話型の git rebase です。
この機能は、Git の「マジックタイムマシン」機能です。このフラグを使うと、変更ベースを作るときにリビジョン履歴に複雑な変更を加えることができます。エラーを隠すことができます！ 多くの小さな変更を、まったく新しい機能パッチにマージすることができます！ リビジョン履歴の表示順を並べ替えましょう！
git rebase -i を実行すると、リベース対象のコミットが一覧表示され、そのコミットに対して実行できるアクションのオプションが表示されます。デフォルトのオプションは select です。
- ピック：歴史に残るコミット。
- 編集: ブランチを再生しながらコミットを変更できます。
Squash: 複数のコミットを1つにマージできます。- ファイルを移動することで、コミットの順番を入れ替えることができます。
完了したら、最終結果を保存するだけで、チェンジベースの操作が実行されます。投稿を修正する各段階で、チェンジベースは停止し、投稿を続ける前に適切な変更を加えることができます。
上の例の結果は、"One-liner bug fix" と "Integate new header everywhere" がひとつのコミットにマージされ、 new header for docs website" と "D oh - typo."は一つのコミットにマージされ、new header for docs website "と "D'oh - typo.Fixed "は別のコミットにマージされました。まるで魔法のように、他のコミットの作業はまだブランチに残っていますが、問題のコミットは履歴から消えています！
これにより、git send-email や新しく整理したパッチセットを使って親リポジトリにプルリクエストを作成し、上流のプロジェクトにクリーンなパッチをコミットすることが簡単になります。これには、コードをレビューしやすくしたり受け入れやすくしたりマージしやすくしたりといったさまざまな利点があります。
