7.6 Gitツール - 履歴の書き換え

最新のコミットを変更することは、おそらく最もよく行う履歴の書き換えでしょう。最後のコミットに対しては、主に2つの基本的なことを行いたいと思うはずです。単純にコミットメッセージを変更するか、あるいはファイルを追加、削除、修正することでコミットの実際のコンテンツを変更するかです。

最後のコミットメッセージだけを修正したい場合は、簡単です。

上記のコマンドは、前のコミットメッセージをエディターセッションにロードします。そこでメッセージに変更を加え、それらの変更を保存して終了できます。エディターを保存して閉じると、エディターはその更新されたコミットメッセージを含む新しいコミットを書き込み、それを新しい最後のコミットとします。

一方、最後のコミットの実際のコンテンツを変更したい場合も、プロセスは基本的に同じです。まず、忘れていたと思われる変更を加え、それらの変更をステージングし、その後のgit commit --amendコマンドが、その最後のコミットを新しい改良されたコミットに置き換えます。

このテクニックを使用する際には注意が必要です。なぜなら、amendはコミットのSHA-1を変更するからです。これは非常に小さなリベースのようなものです。すでにプッシュした最後のコミットをamendしないようにしてください。

履歴のさらに奥にあるコミットを修正するには、より複雑なツールに移行する必要があります。Gitには履歴を修正する直接的なツールはありませんが、リベースツールを使って一連のコミットを、元々それらが基づいていたHEADにリベースすることで、別のHEADに移動させるのではなく、元の位置で変更できます。インタラクティブなリベースツールを使用すると、変更したい各コミットの後に停止し、メッセージを変更したり、ファイルを追加したり、好きなことを何でもできます。git rebaseに-iオプションを追加することで、インタラクティブにリベースを実行できます。コミットをどれだけ遡って書き換えたいかを、どのコミットをリベースの基点にするかをコマンドに指示することで指定する必要があります。

たとえば、最後の3つのコミットメッセージ、またはそのグループ内のいずれかのコミットメッセージを変更したい場合、git rebase -iの引数として、編集したい最後のコミットの親であるHEAD~2^またはHEAD~3を指定します。最後の3つのコミットを編集しようとしているため、~3の方が覚えやすいかもしれませんが、実際には4つ前のコミット、つまり編集したい最後のコミットの親を指定していることに留意してください。

これはリベースコマンドであるということを再度覚えておいてください。HEAD~3..HEADの範囲内でメッセージが変更されたコミット、およびそのすべての子孫は書き換えられます。すでにセントラルサーバーにプッシュしたコミットは含めないでください。そうすると、他の開発者に同じ変更の代替バージョンを提供することになり、混乱を招きます。

このコマンドを実行すると、テキストエディターに次のようなコミットのリストが表示されます。

これらのコミットが、通常logコマンドで表示される順序とは逆の順序でリストされていることに注意することが重要です。logを実行すると、次のような表示になります。

逆順であることに注目してください。インタラクティブなリベースは、実行するスクリプトを提供します。コマンドラインで指定したコミット（HEAD~3）から開始し、これらの各コミットで導入された変更を上から下へと再適用します。最新のものではなく、最も古いものが上部にリストされます。なぜなら、それが最初に再適用されるからです。

編集したいコミットで停止するようにスクリプトを編集する必要があります。そのためには、スクリプトが停止するようにしたい各コミットの「pick」という単語を「edit」という単語に変更します。たとえば、3番目のコミットメッセージのみを修正したい場合は、ファイルを次のように変更します。

エディターを保存して終了すると、Gitはリストの最後のコミットまで巻き戻し、次のメッセージを表示してコマンドラインに戻します。

これらの指示は、何をすべきかを正確に教えてくれます。次のように入力します。

コミットメッセージを変更し、エディターを終了します。その後、次を実行します。

このコマンドは他の2つのコミットを自動的に適用し、これで完了です。もし、複数の行で`pick`を`edit`に変更した場合、`edit`に変更した各コミットに対してこれらのステップを繰り返すことができます。そのたびにGitは停止し、コミットを修正させ、完了したら続行します。

インタラクティブなリベースを使って、コミットを並べ替えたり、完全に削除したりすることもできます。もし「Add cat-file」コミットを削除し、他の2つのコミットが導入される順序を変更したい場合、リベーススクリプトを次のように変更できます。

これを次のようにします。

エディターを保存して終了すると、Gitはブランチをこれらのコミットの親まで巻き戻し、310154eを適用し、次にf7f3f6dを適用して停止します。これにより、それらのコミットの順序が効果的に変更され、「Add cat-file」コミットは完全に削除されます。

一連のコミットをインタラクティブなリベースツールで単一のコミットにスカッシュすることも可能です。スクリプトはリベースメッセージに役立つ指示を置きます。

「pick」や「edit」の代わりに「squash」を指定すると、Gitはその変更と直前の変更の両方を適用し、コミットメッセージをマージさせます。したがって、これら3つのコミットから単一のコミットを作成したい場合、スクリプトを次のようにします。

エディターを保存して終了すると、Gitは3つの変更すべてを適用し、その後、3つのコミットメッセージをマージするためにエディターに戻ります。

それを保存すると、以前の3つのコミットの変更をすべて導入する単一のコミットが得られます。

コミットを分割するには、コミットを取り消し、その後、最終的に必要な数のコミットになるまで部分的にステージングしコミットします。たとえば、3つのコミットの真ん中のコミットを分割したいとします。「Update README formatting and add blame」の代わりに、「Update README formatting」（最初のコミット）と「Add blame」（2番目のコミット）の2つのコミットに分割したいとします。これは、分割したいコミットの指示を「edit」に変更することで、rebase -iスクリプトで行うことができます。

その後、スクリプトがコマンドラインに戻ったとき、そのコミットをリセットし、リセットされた変更を取り込み、それらから複数のコミットを作成します。エディターを保存して終了すると、Gitはリストの最初のコミット（f7f3f6d）の親まで巻き戻り、最初のコミット（f7f3f6d）を適用し、2番目のコミット（310154e）を適用し、コンソールに戻ります。そこで、git reset HEAD^でそのコミットをmixedリセットできます。これは事実上そのコミットを取り消し、変更されたファイルをステージされていない状態のままにします。これで、複数のコミットを作成するまでファイルをステージングしてコミットし、完了したらgit rebase --continueを実行できます。

Gitはスクリプト内の最後のコミット（a5f4a0d）を適用し、履歴は次のようになります。

これにより、リスト内の最も新しい3つのコミットのSHA-1が変更されますので、共有リポジトリにすでにプッシュした変更済みコミットがこのリストに含まれていないことを確認してください。リストの最後のコミット（f7f3f6d）は変更されていないことに注目してください。このコミットはスクリプトに表示されていますが、「pick」とマークされ、リベースの変更が適用される前に適用されたため、Gitはそのコミットを変更しません。

コミットを削除したい場合は、rebase -iスクリプトを使用して削除できます。コミットのリストで、削除したいコミットの前に「drop」という単語を置くか（またはリベーススクリプトからその行を削除するだけです）

Gitがコミットオブジェクトを構築する方法のため、コミットを削除または変更すると、それに続くすべてのコミットが書き換えられます。リポジトリの履歴を遡れば遡るほど、より多くのコミットが再作成される必要があります。これは、削除したばかりのコミットに依存するコミットがシーケンスの後半に多数ある場合、多くのマージコンフリクトを引き起こす可能性があります。

このようなリベースの途中で、それが良い考えではないと判断した場合、いつでも停止できます。git rebase --abortと入力すると、リポジトリはリベースを開始する前の状態に戻されます。

リベースを完了し、それが望むものではないと判断した場合は、git reflogを使用して、ブランチの以前のバージョンを回復できます。reflogコマンドの詳細については、データリカバリを参照してください。

もし、多数のコミットをスクリプトで書き換える必要がある場合（たとえば、メールアドレスをグローバルに変更したり、すべてのコミットからファイルを削除したりする場合）に利用できる、もう一つの履歴書き換えオプションがあります。そのコマンドはfilter-branchであり、履歴の広範な範囲を書き換えることができます。したがって、プロジェクトがまだ公開されておらず、他の人が書き換えようとしているコミットに基づいて作業を進めていない限り、おそらく使用すべきではありません。しかし、これは非常に役立つ場合があります。その能力の一端を理解してもらうために、いくつかの一般的な使用例を学びます。