7.7 Git ツール - Reset の解明

HEAD は現在のブランチ参照へのポインタであり、これはそのブランチで最後に行われたコミットへのポインタです。つまり、HEAD は次に作成されるコミットの親になります。HEAD は、そのブランチでの最後のコミットのスナップショットと考えるのが最も簡単です。

実際、そのスナップショットがどのようなものかを見るのは非常に簡単です。HEAD スナップショット内の各ファイルの実際のディレクトリリストと SHA-1 チェックサムを取得する例を次に示します。

Git の cat-file コマンドと ls-tree コマンドは、より低レベルな目的に使用され、日常業務ではあまり使用されない「配管」コマンドですが、ここで何が起こっているかを見るのに役立ちます。

インデックスは、次に提案されるコミットです。この概念を Git の「ステージングエリア」とも呼んでいますが、これは git commit を実行するときに Git が参照するものです。

Git は、最後にワーキングディレクトリにチェックアウトされたすべてのファイルの内容と、最初にチェックアウトされたときの状態のリストでこのインデックスを初期化します。その後、それらのファイルの一部を新しいバージョンに置き換え、git commit がそれを新しいコミットのツリーに変換します。

ここでも git ls-files を使用していますが、これは舞台裏のコマンドであり、現在のインデックスがどのようなものかを示します。

インデックスは厳密にはツリー構造ではありません。実際にはフラットなマニフェストとして実装されていますが、私たちの目的には十分近いです。

最後に、ワーキングディレクトリ（一般的には「作業ツリー」とも呼ばれます）があります。他の2つのツリーは、.git フォルダー内に効率的ですが不便な方法でコンテンツを保存します。ワーキングディレクトリはそれらを実際のファイルに展開するため、編集がはるかに簡単になります。ワーキングディレクトリはサンドボックスと見なしてください。変更をステージングエリア（インデックス）、そして履歴にコミットする前に、そこで変更を試すことができます。

reset が最初に行うことは、HEAD が指すものを移動することです。これは HEAD 自体を変更する（checkout が行うこと）のとは異なります。reset は HEAD が指しているブランチを移動します。つまり、HEAD が master ブランチに設定されている場合（つまり、現在 master ブランチにいる場合）、git reset 9e5e6a4 を実行すると、まず master が 9e5e6a4 を指すように変更されます。

コミットを伴う reset のどの形式を呼び出しても、これは常に最初に行われることです。reset --soft を使用すると、そこで停止します。

ここで少し時間を取ってこの図を見て、何が起こったのかを理解してください。それは本質的に最後の git commit コマンドを取り消しました。git commit を実行すると、Git は新しいコミットを作成し、HEAD が指すブランチをそれに移動させます。reset で HEAD~（HEAD の親）に戻ると、インデックスやワーキングディレクトリを変更せずにブランチを元の場所に戻すことになります。これでインデックスを更新し、再度 git commit を実行して、git commit --amend が行ったことを達成できます（最後のコミットの変更を参照）。

ここで git status を実行すると、インデックスと新しい HEAD との差が緑色で表示されることに注意してください。

reset が次に行うことは、HEAD が現在指しているスナップショットの内容でインデックスを更新することです。

--mixed オプションを指定すると、reset はこの時点で停止します。これはデフォルトでもあり、オプションをまったく指定しない場合（この場合は単に git reset HEAD~）、コマンドはここで停止します。

ここで少し時間を取ってこの図を見て、何が起こったのかを理解してください。まだ最後の commit は取り消されましたが、すべてが**アンステージ**されました。すべての git add および git commit コマンドを実行する前に戻ったことになります。

reset が行う3つ目のことは、ワーキングディレクトリをインデックスのようにすることです。--hard オプションを使用すると、この段階まで続行されます。

では、何が起こったのか考えてみましょう。最後のコミット、git add と git commit コマンド、**そして**ワーキングディレクトリで行った作業すべてを取り消しました。

このフラグ (--hard) が reset コマンドを危険にする唯一の方法であり、Git が実際にデータを破壊する非常に数少ないケースの1つであることに注意することが重要です。他の reset の呼び出しは非常に簡単に元に戻すことができますが、--hard オプションはワーキングディレクトリ内のファイルを強制的に上書きするため、元に戻すことはできません。この特定のケースでは、ファイルの**v3**バージョンがまだ Git DB のコミットに存在しており、reflog を見てそれを取り戻すことができますが、コミットしていなかった場合は、Git がファイルを上書きし、回復不能になっていたでしょう。

reset コマンドは、指定された順序でこれら3つのツリーを上書きし、指定した時点で停止します。

git checkout [branch] を実行することは git reset --hard [branch] を実行することとかなり似ており、3つのツリーすべてを [branch] のように更新しますが、2つの重要な違いがあります。

まず、reset --hard とは異なり、checkout はワーキングディレクトリに安全です。変更されたファイルが失われないことを確認します。実際には、それよりも少し賢く、ワーキングディレクトリで自明なマージを試みるため、変更していないファイルはすべて更新されます。一方、reset --hard は、チェックせずにすべてを全面的に置き換えます。

2つ目の重要な違いは、checkout が HEAD を更新する方法です。reset は HEAD が指すブランチを移動しますが、checkout は HEAD 自体を移動して別のブランチを指すようにします。

たとえば、異なるコミットを指す master と develop ブランチがあり、現在 develop にいるとします（そのため HEAD は develop を指しています）。git reset master を実行すると、develop 自体は master と同じコミットを指すようになります。代わりに git checkout master を実行すると、develop は移動せず、HEAD 自体が移動します。HEAD は master を指すようになります。

したがって、どちらの場合も HEAD をコミット A を指すように移動しますが、その方法は大きく異なります。reset は HEAD が指すブランチを移動し、checkout は HEAD 自体を移動します。

checkout を実行するもう1つの方法はファイルパスを使用することです。これは reset と同様に HEAD を移動しません。git reset [branch] file と同じように、そのコミットにあるそのファイルでインデックスを更新するだけでなく、ワーキングディレクトリ内のファイルも上書きします。これは git reset --hard [branch] file とまったく同じです（もし reset でそれを実行できるなら） — ワーキングディレクトリに安全ではなく、HEAD も移動しません。

また、git reset や git add と同様に、checkout は --patch オプションを受け入れ、ハンクごとにファイルコンテンツを選択的に元に戻すことができます。