7.7 Git のさまざまなツール - リセットコマンド詳説

reset と checkout を単純化したいので、Git を「3つのツリーのデータを管理するためのツール」と捉えてしまいましょう。 なお、ここでいう「ツリー」とはあくまで「ファイルの集まり」であって、データ構造は含みません。 （Git のインデックスがツリーとは思えないようなケースもありますが、ここでは単純にするため、「ツリー＝ファイルの集まり」で通していきます。）

いつものように Git を使っていくと、以下のツリーを管理・操作していくことになります。

Git を使う主目的は、プロジェクトのスナップショットを健全な状態で取り続けることです。そのためには、3つのツリーを操作する必要があります。

その手順を頭を使って説明しましょう。まず、新しいディレクトリを作って、テキストファイルをひとつ保存したとします。 現段階でのこのファイルを v1 としましょう（図では青塗りの部分）。 次に git init を実行して Git リポジトリを生成します。このときの HEAD は、これから生成される予定のブランチを指し示すことになります（ master はまだ存在しません）。

この時点では、作業ディレクトリにしかテキストファイルのデータは存在しません。

では、このファイルをコミットしてみましょう。まずは git add を実行して、作業ディレクトリ上のデータをインデックスにコピーします。

さらに、git commit を実行し、インデックスの内容でスナップショットを作成します。そうすると、作成したスナップショットをもとにコミットオブジェクトが作成され、master がそのコミットを指し示すようになります。

この段階で git status を実行しても、何も変更点は出てきません。3つのツリーが同じ状態になっているからです。

続いて、このテキストファイルの内容を変更してからコミットしてみましょう。 手順はさきほどと同じです。まずは、作業ディレクトリにあるファイルを変更します。 変更した状態のファイルを v2 としましょう（図では赤塗りの部分）。

git status をここで実行すると、コマンド出力の “Changes not staged for commit” 欄に赤塗り部分のファイルが表示されます。作業ディレクトリ上のそのファイルの状態が、インデックスの内容とは異なっているからです。 では、git add を実行して変更をインデックスに追加してみましょう。

この状態で git status を実行すると、以下の図で緑色の枠内にあるファイルがコマンド出力の “Changes to be committed” 欄 に表示されます。インデックスと HEAD の内容に差分があるからです。次のコミット候補と前回のコミットの内容に差異が生じた、とも言えます。 では、git commit を実行してコミット内容を確定させましょう。

ここで git status を実行しても何も出力されません。3つのツリーが同じ状態に戻ったからです。

なお、ブランチを切り替えたりリモートブランチをクローンしても同じような処理が走ります。 ブランチをチェックアウトしたとしましょう。そうすると、HEAD はそのブランチを指すようになります。さらに、HEAD コミットのスナップショットで インデックス が上書きされ、そのデータが 作業ディレクトリ にコピーされます。

これから説明する内容に沿って考えれば、reset コマンドの役割がわかりやすくなるはずです。

説明で使う例として、さきほど使った file.txt をまた編集し、コミットしたと仮定します。その場合、このリポジトリの歴史は以下のようになります。

では、reset コマンドの処理の流れを順を追って見ていきましょう。単純な方法で3つのツリーが操作されていきます。 一連の処理は、最大で3つになります。

ここまでで、reset の基礎と言える部分を説明してきました。次に、パスを指定して実行した場合の挙動について説明します。 パスを指定して reset を実行すると、処理1は省略されます。また、処理2と3については、パスで指定された範囲（ファイル郡）に限って実行されます。 このように動作するのはもっともな話です。処理1で操作される HEAD はポインタにすぎず、指し示せるコミットは一つだけだからです（こちらのコミットのこの部分と、あちらのコミットのあの部分、というようには指し示せません）。 一方、インデックスと作業ディレクトリを一部分だけ更新することは 可能 です。よって、リセットの処理2と3は実行されます。

実際の例として、 git reset file.txt を実行したらどうなるか見ていきましょう。 このコマンドは git reset --mixed HEAD file.txt のショートカット版（ブランチやコミットの SHA-1 の指定がなく、 --soft or --hard の指定もないため）です。実行すると、

が行われます。要は、HEAD からインデックスに file.txt がコピーされるということです。

同時に、このコマンドは指定したファイルをステージされていない状態に戻す（ unstage )、ということでもあります。 上の図（リセットコマンドを図示したもの）を念頭におきつつ、git add の挙動を考えてみてください。真逆であることがわかるはずです。

なお、ファイルをステージされていない状態に戻したいときはこのリセットコマンドを実行するよう、 git status コマンドの出力には書かれています。その理由は、リセットコマンドが上述のような挙動をするからなのです。 （詳細は ステージしたファイルの取り消し を確認してください）。

「HEAD のデータが欲しい」という前提で処理が行われるのを回避することもできます。とても簡単で、必要なデータを含むコミットを指定するだけです。 git reset eb43bf file.txt のようなコマンドになります。

これを実行すると、作業ディレクトリ上の file.txt が v1 の状態に戻り、git add が実行されたあと、作業ディレクトリの状態が v3 に戻る、のと同じことが起こります（実際にそういった手順で処理されるわけではありませんが）。 さらに git commit を実行してみましょう。すると、作業ディレクトリ上の状態をまた v1 に戻したわけではないのに、該当のファイルを v1 に戻す変更がコミットされます。

もうひとつ、覚えておくべきことを紹介します。 git add などと同じように、reset コマンドにも --patch オプションがあります。これを使うと、ステージした内容を塊ごとに作業ディレクトリに戻せます。 つまり、一部分だけを作業ディレクトリに戻したり以前の状態に巻き戻したりできるわけです。

本節で学んだ方法を使う、気になる機能を紹介します。コミットのまとめ機能です。

「凡ミス」「WIP」「ファイル追加忘れ」のようなメッセージのコミットがいくつも続いたとします。 そんなときは reset を使いましょう。すっきりと一つにまとめられます （別の手段を コミットのまとめ で紹介していますが、今回の例では reset の方がわかりやすいと思います）。

ここで、最初のコミットはファイル数が1、次のコミットでは最初からあったファイルの変更と新たなファイルの追加、その次のコミットで最初からあったファイルをまた変更、というコミット履歴を経てきたプロジェクトがあったとします。 二つめのコミットは作業途中のもの（WIP）だったので、どこかにまとめてしまいましょう。

まず、git reset --soft HEAD~2 を実行して HEAD を過去のコミット（消したくはないコミットのうち古い方）へと移動させます。

そうしたら、あとは git commit を実行するだけです。

こうしてしまえば、1つめのコミットで file-a.txt v1 が追加され、2つめのコミットで file-a.txt が v3 に変更され file-b.txt が追加された、というコミット履歴が到達可能な歴史（プッシュすることになる歴史）になります。file-a.txt を v2 に変更したコミットを歴史から取り除くことができました。

最後に、checkout と reset の違いについて触れておきます。 3つのツリーを操作する、という意味では checkout は reset と同様です。けれど、コマンド実行時にファイルパスを指定するかどうかによって、少し違いがでてきます。

これまでの説明で reset コマンドについての不安は解消されたでしょうか。checkout との違いがまだまだ曖昧かもしれません。実行の仕方が多すぎて、違いを覚えるのは無理と言っても言い過ぎではないはずです。

どのコマンドがどのツリーを操作するか、以下の表にまとめておきました。 “HEAD” の列は、該当のコマンドが HEAD が指し示すブランチの位置を動かす場合は “REF”、動くのが HEAD そのものの場合は “HEAD” としてあります。 「作業ディレクトリ保護の有無」の列はよく見ておいてください。その列が いいえ の場合は、実行結果をよくよく踏まえてからコマンドを実行するようにしてください。