7.7 Gitツール - リセット徹底解説

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が指しているブランチをそのコミットに移動します。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オプションは、作業ディレクトリのファイルを強制的に上書きするため、元に戻すことができません。この特定のケースでは、Git DBのコミットにファイルのv3バージョンはまだあり、reflogを確認することで復元できますが、コミットしていなかった場合は、Gitはまだファイルを上書きし、復元できなくなります。

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

git checkout [ブランチ]を実行することは、git reset --hard [ブランチ]を実行することと非常によく似ており、[ブランチ]のように見えるように3つのツリーすべてを更新しますが、2つの重要な違いがあります。

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

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

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

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

checkoutを実行するもう一つの方法は、ファイルパスを指定する方法です。これはresetと同様にHEADを移動しません。これは、そのコミットでのそのファイルを使用してインデックスを更新するという点でgit reset [ブランチ] ファイルと同じですが、作業ディレクトリのファイルも上書きします。これはgit reset --hard [ブランチ] ファイル（もしresetがそれを実行できたとしたら）と全く同じです。作業ディレクトリは安全ではなく、HEADは移動しません。

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