7.7 Gitツール - Resetを解明する

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

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

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

インデックスはあなたの提案された次のコミットです。私たちはこの概念を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が指すブランチをそのコミットまで移動させます。HEAD~（HEADの親）までresetすると、インデックスやワーキングディレクトリを変更せずに、ブランチを元の場所に戻すことになります。これでインデックスを更新し、再び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を実行するもう一つの方法はファイルパスを指定する方法で、これはresetと同様にHEADを移動させません。特定のコミットのファイルでインデックスを更新するという点でgit reset [branch] fileと似ていますが、ワーキングディレクトリのファイルも上書きします。これはまさにgit reset --hard [branch] file（もしresetがそれを実行させてくれるなら）と同じです。ワーキングディレクトリに対して安全ではなく、HEADも移動させません。

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