7.6 Git のさまざまなツール - 歴史の書き換え

直近のコミットを変更するというのは、歴史を書き換える作業のうちもっともよくあるものでしょう。 直近のコミットに対して手を加えるパターンとしては、コミットメッセージを変更したりそのコミットで記録されるスナップショットを変更 (ファイルを追加・変更あるいは削除) したりといったものがあります。

単に直近のコミットメッセージを変更したいだけの場合は非常にシンプルです。

これを実行するとテキストエディタが開きます。すでに直近のコミットメッセージが書き込まれた状態になっており、それを変更することができます。 変更を保存してエディタを終了すると、変更後のメッセージを含む新しいコミットを作成して直近のコミットをそれで置き換えます。

いったんコミットしたあとで、そこにさらにファイルを追加したり変更したりしたくなったとしましょう。「新しく作ったファイルを追加し忘れた」とかがありそうですね。この場合の手順も基本的には同じです。 ファイルを編集して git add したり追跡中のファイルを git rm したりしてステージングエリアをお好みの状態にしたら、続いて git commit --amend を実行します。すると、現在のステージングエリアの状態を次回のコミット用のスナップショットにします。

この技を使う際には注意が必要です。この処理を行うとコミットの SHA-1 が変わるからです。 いわば、非常に小規模なリベースのようなものです。すでにプッシュしているコミットは書き換えないようにしましょう。

さらに歴史をさかのぼったコミットを変更したい場合は、もう少し複雑なツールを使わなければなりません。 Git には歴史を修正するツールはありませんが、リベースツールを使って一連のコミットを (別の場所ではなく) もともとあった場所と同じ HEAD につなげるという方法を使うことができます。 対話的なリベースツールを使えば、各コミットについてメッセージを変更したりファイルを追加したりお望みの変更をすることができます。 対話的なリベースを行うには、git rebase に -i オプションを追加します。 どこまでさかのぼってコミットを書き換えるかを指示するために、どのコミットにリベースするかを指定しなければなりません。

直近の三つのコミットメッセージあるいはそのいずれかを変更したくなった場合、変更したい最古のコミットの親を git rebase -i の引数に指定します。ここでは HEAD~2^ あるいは HEAD~3 となります。 直近の三つのコミットを編集しようと考えているのだから、~3 のほうが覚えやすいでしょう。しかし、実際のところは四つ前 (変更したい最古のコミットの親) のコミットを指定していることに注意しましょう。

これはリベースコマンドであることを認識しておきましょう。 HEAD~3..HEAD に含まれるすべてのコミットは、実際にメッセージを変更したか否かにかかわらずすべて書き換えられます。 すでに中央サーバーにプッシュしたコミットをここに含めてはいけません。含めてしまうと、同じ変更が別のバージョンで見えてしまうことになって他の開発者が混乱します。

このコマンドを実行すると、テキストエディタが開いてコミットの一覧が表示され、このようになります。

このコミット一覧の表示順は、log コマンドを使ったときの通常の表示順とは逆になることに注意しましょう。 log を実行すると、このようになります。

逆順になっていますね。 対話的なリベースを実行するとスクリプトが出力されるので、それをあとで実行することになります。 このスクリプトはコマンドラインで指定したコミット (HEAD~3) から始まり、それ以降のコミットを古い順に再現していきます。 最新のものからではなく古いものから表示されているのは、最初に再現するのがいちばん古いコミットだからです。

このスクリプトを編集し、手を加えたいコミットのところでスクリプトを停止させるようにします。そのためには、各コミットのうちスクリプトを停止させたいものについて「pick」を「edit」に変更します。たとえば、三番目のコミットメッセージだけを変更したい場合はこのようにファイルを変更します。

これを保存してエディタを終了すると、Git はそのリストの最初のコミットまで処理を巻き戻し、次のようなメッセージとともにコマンドラインを返します。

この指示が、まさにこれからすべきことを教えてくれています。

と打ち込んでコミットメッセージを変更してからエディタを終了し、次に

を実行します。このコマンドはその他のふたつのコミットも自動的に適用するので、これで作業は終了です。 複数行で「pick」を「edit」に変更した場合は、これらの作業を各コミットについてくりかえすことになります。 それぞれの場面で Git が停止するので、amend でコミットを書き換えて continue で処理を続けます。

対話的なリベースで、コミットの順番を変更したり完全に消し去ってしまったりすることもできます。 “added cat-file” のコミットを削除して残りの二つのコミットの適用順を反対にしたい場合は、リベーススクリプトを

から

のように変更します。これを保存してエディタを終了すると、Git はまずこれらのコミットの親までブランチを巻き戻してから 310154e を適用し、その次に f7f3f6d を適用して停止します。 これで、効率的にコミット順を変更して “added cat-file” のコミットは完全に取り除くことができました。

一連のコミット群をひとつのコミットにまとめて押し込んでしまうことも、対話的なリベースツールで行うことができます。リベースメッセージの中に、その手順が出力されています。

「pick」や「edit」のかわりに「squash」を指定すると、Git はその変更と直前の変更をひとつにまとめて新たなコミットメッセージを書き込めるようにします。 つまり、これらの三つのコミットをひとつのコミットにまとめたい場合は、スクリプトをこのように変更します。

これを保存してエディタを終了すると、Git は三つの変更をすべて適用してからエディタに戻るので、そこでコミットメッセージを変更します。

これを保存すると、さきほどの三つのコミットの内容をすべて含んだひとつのコミットができあがります。

コミットの分割は、いったんコミットを取り消してから部分的なステージとコミットを繰り返して行います。 たとえば、先ほどの三つのコミットのうち真ん中のものを分割することになったとしましょう。 “updated README formatting and added blame” のコミットを、“updated README formatting” と “added blame” のふたつに分割します。 そのためには、rebase -i スクリプトを実行してそのコミットの指示を「edit」に変更します。

続いて、コマンドラインに戻ってコミットをリセットし、その内容を使ってコミットを複数に分割していきます。 まず、変更を保存してエディタを終了すると、Git はリストの最初のコミットの親まで処理を巻き戻します。そして最初のコミット (f7f3f6d) と二番目のコミット (310154e) を適用してからコンソールに戻ります。 コミットをリセットするには git reset HEAD^ を実行します。これはコミット自体を取り消し、変更されたファイルはステージしていない状態にします。 そして、その状態から一連のコミットを作ったら、以下のように`git rebase --continue` を実行しましょう｡

Git はスクリプトの最後のコミット (a5f4a0d) を適用し、歴史はこのようになります。

念のためにもう一度言いますが、この変更はリスト内のすべてのコミットの SHA を変更します。すでに共有リポジトリにプッシュしたコミットは、このリストに表示させないようにしましょう。

歴史を書き換える方法がもうひとつあります。これは、大量のコミットの書き換えを機械的に行いたい場合 (メールアドレスを一括変更したりすべてのコミットからあるファイルを削除したりなど) に使うものです。 そのためのコマンドが filter-branch です。これは歴史を大規模にばさっと書き換えることができるものなので、プロジェクトを一般に公開した後や書き換え対象のコミットを元にしてだれかが作業を始めている場合はまず使うことはありません。 しかし、これは非常に便利なものでもあります。 一般的な使用例をいくつか説明するので、それをもとにこの機能を使いこなせる場面を考えてみましょう。