Git のリセット

最初に調べるツリーは「作業ディレクトリ」です。このツリーはローカルファイルシステムと同期しており、ファイルとディレクトリへの変更はこのツリーに即座に反映されます。

デモ リポジトリでは、reset_lifecycle_file を修正してコンテンツを追加しています。git status を呼び出すと、ファイルへの変更を Git が認識していることがわかります。これらの変更は現在、1 つ目のツリーである「作業ディレクトリ」に属しています。git status を使って作業ディレクトリへの変更を表示できます。変更は「modified」のプレフィックスが付いた赤字で表示されます。

次に「ステージング インデックス」ツリーを見ていきます。このツリーは、git add でプロモートされて後続のコミットに保存される作業ディレクトリの変更を追跡します。このツリーは、複雑な内部キャッシュ メカニズムです。Git では通常、ステージング インデックスの実装の詳細をユーザーから隠そうとします。

ステージング インデックスの状態を正確に表示するには、あまり知られていない git コマンド git ls-files を使用する必要があります 。git ls-files コマンドは、基本的にステージング インデックス ツリーの状態を検査するためのデバッグ ユーティリティです。

ここでは、-s または --stage オプションで git ls-files を実行しました。-s オプションを指定しない場合、git ls-files 出力にはインデックスに現在属しているファイル名とパスのリストだけが表示されます。-s オプションではステージング インデックスのファイルの追加メタデータが表示されます。このメタデータはステージされたコンテンツのモード ビット、オブジェクト名、ステージ番号です。ここでは 2 番目の値 (d7d77c1b04b5edd5acfc85de0b592449e5303770) であるオブジェクト名に注目します。これは標準の git オブジェクト SHA-1 ハッシュで、ファイルのコンテンツのハッシュです。コミット履歴にはコミットと ref へのポインターを識別するための独自のオブジェクト SHA ハッシュが保存されています。ステージング インデックスにはインデックス内のファイルのバージョンを追跡するための独自のオブジェクト SHA ハッシュがあります。

次に、修正した reset_lifecycle_file をステージング インデックスにプロモートします。

ここではステージング インデックスにファイルを追加する git add reset_lifecycle_file を呼び出しました。ここで git status を呼び出すと「コミットされる変更」の下に緑で reset_lifecycle_file が表示されます。git status は実際にはステージング インデックスを表していないため、注意が必要です。git status コマンドの出力には、コミット履歴とステージング インデックスの間の変更が表示されています。この時点のステージング インデックスのコンテンツを調べてみましょう。

reset_lifecycle_file のオブジェクト SHA が e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 から d7d77c1b04b5edd5acfc85de0b592449e5303770 に更新されていることがわかります。

最後のツリーは、コミット履歴です。git commit コマンドは、コミット履歴内にある永続的なスナップショットに変更を追加します。このスナップショットには、コミット時のステージング インデックスの状態も含まれます。

ここでは、「resetlifecyclefile の内容を更新する」というメッセージで新しいコミットを作成しました。チェンジセットがコミット履歴に追加されました。この時点で git status を呼び出すと、ツリーには保留中の変更がないと表示されます。git log を実行すると、コミット履歴が表示されます。3 つのツリーに沿ってこのチェンジセットを追ってきたので、git reset の利用を開始できます。

この例では、main ブランチの連続するコミットを詳しく見ていきました。現在、HEAD ref と main ブランチ ref はコミット d を指しています。それでは、git checkout b と git reset b の両方を実行して結果を比較してみましょう。

git checkout を実行しても、main ref は d を指したしたままです。HEAD ref が移動してコミット b を指しています。現在、このリポジトリは「detached HEAD」状態になっています。

対照的に、git reset は HEAD とブランチ ref の両方を指定したコミットに移動します。

git reset はコミットの ref ポインターを更新するだけでなく、3 つのツリーの状態を修正します。ref ポインターの修正は常に発生していて、3 番目のツリーであるコミット ツリーが更新されます。コマンド ライン引数 --soft、--mixed、--hard でステージング インデックス ツリーと作業ディレクトリ ツリーの修正方法を指定します。

これは最も直接的かつ「危険」で使用頻度の高いオプションです。--hard を渡すと、コミット履歴の ref ポインターが指定したコミットに更新されます。その後、ステージング インデックスと作業ディレクトリは、指定したコミットの状態と同じになるようにリセットされます。ステージング インデックスと作業ディレクトリでこれまで保留されていたすべての変更は、コミット ツリーの状態と同じになるようにリセットされます。つまり、ステージング インデックスと作業ディレクトリで確定していないすべての保留中の変更が失われることになります。

これを実証するために、先ほど確立した 3 つのツリーのサンプル リポジトリを続けてみましょう。まず、リポジトリにいくつかの変更を加えましょう。サンプル リポジトリで次のコマンドを実行します。

これらのコマンドにより、new_file という名前の新しいファイルが作成され、リポジトリに追加されました。さらに、reset_lifecycle_file の内容が変更されます。これらの変更を適用し、git status を使用してリポジトリの状態を調べてみましょう。

ここではステージング インデックスにファイルを追加する git add reset_lifecycle_file を呼び出しました。ここで git status を呼び出すと「コミットされる変更」の下に緑で reset_lifecycle_file が表示されます。git status は実際にはステージング インデックスを表していないため、注意が必要です。git status コマンドの出力には、コミット履歴とステージング インデックスの間の変更が表示されています。この時点のステージング インデックスのコンテンツを調べてみましょう。

new_file がインデックスに追加されていることがわかります。reset_lifecycle_file を更新しましたが、ステージング インデックス SHA (d7d77c1b04b5edd5acfc85de0b592449e5303770) は変わっていません。ステージング インデックスにこれらの変更をプロモートするために git add を使用していないので、この挙動は予想通りです。これらの変更は作業ディレクトリに留まっています。

git reset --hard を実行して、リポジトリの新しい状態を調べましょう。

ここでは、--hard オプションを使って「ハード リセット」を実行しました。Git には、HEAD が最新のコミット dc67808 をポイントしていることを示す出力が表示されています。次は、git status を実行してリポジトリの状態を確認してみましょう。Git には保留中の変更がないことがわかります。ステージング インデックスの状態も調べると new_file が追加される前の時点にリセットされていることがわかります。reset_lifecycle_file に加えた変更と new_file の追加は失われたことになります。このようなデータの消失は元に戻せないという点を忘れないでください。

デフォルトの操作モードで、ref ポインターが更新されます。ステージングインデックスは、指定したコミットの状態にリセットされます。ステージングインデックスで元に戻したすべての変更は作業ディレクトリに移動します。それでは実際にやってみましょう。

上のサンプルではリポジトリにいくつか修正を加えました。ここでも、new_file を追加して reset_lifecycle_file のコンテンツを修正しています。これらの変更はその後、git add を使用してステージング インデックスに適用されます。リポジトリがこの状態になったので、リセットを実行してみましょう。

ここでは「混合リセット」を実行しました。繰り返しになりますが、--mixed はデフォルトのモードで、git reset 実行時と同じ結果が得られます。git status と git ls-files の出力を調べてみると、インデックス内に reset_lifecycle_file のファイルしかない状態に、ステージング インデックスがリセットされていることがわかります。reset_lifecycle_file のオブジェクト SHA が以前のバージョンにリセットされています。

ここで重要なのは、git status によって、reset_lifecycle_file に修正が入っていることと、追跡対象外ファイル new_file があることがわかったことです。これは明示的な --mixed の明示的な挙動です。ステージング インデックスがリセットされて、保留中の変更が作業ディレクトリに移動されました。対照的に、--hard を使ったリセットのケースではステージング インデックスと作業ディレクトリの両方がリセットされて更新が失われていました。

--soft 引数が渡されると、ref ポインターが更新されてそこでリセットが停止します。ステージング インデックスと作業ディレクトリは変更されません。この挙動をわかりやすく説明するのは簡単ではありません。引き続きデモ用リポジトリを使ってソフト リセットの準備を行いましょう。

ここでも git add を使って、修正した reset_lifecycle_file をステージング インデックスにプロモートしました。インデックスが git ls-files の出力で更新されているのがわかります。git status の出力には「コミットされる変更」が緑で表示されています。前のサンプルの new_file が、追跡対象外ファイルとして作業ディレクトリで未確定状態になっています。以降のサンプルでは不要なので、rm new_file を実行してこのファイルを削除しましょう。

リポジトリがこの状態になったので、ソフト リセットを実行してみましょう。

「ソフト リセット」を実行しました。git status と git ls-files を実行してリポジトリの状態を確認すると、何も変更されていないことがわかります。これは想定された挙動です。ソフト リセットではコミット履歴だけがリセットされます。デフォルトでは、git reset は HEAD とともにターゲット コミットとして呼び出されます。今回のコミット履歴はすでに HEAD にあるため、HEAD に暗黙的にリセットしても実際には何も起こりません。

--soft の理解を深めてうまく使えるようになるために、HEAD ではないターゲット コミットを用意する必要があります。ステージング インデックスには reset_lifecycle_file があるので、新しいコミットを作成してみましょう。

この時点で、リポジトリには 3 つのコミットがあるはずです。1 つ目のコミットまで時間をさかのぼりましょう。これを行うには 1 つ目のコミットの ID が必要です。git log の出力を見ると ID がわかります。

コミット履歴 ID は各システムで固有だということを覚えておきましょう。つまり、このサンプルのコミット ID と、ご自身のコンピューターに表示されているコミット ID は異なっているということです。このサンプルで使うコミット ID は 780411da3b47117270c0e3a8d5dcfd11d28d04a4 です。これが「最初のコミット」に対応する ID です。ID がわかったらそれを対象として指定してソフト リセットを実行します。

復習する前に、まずはリポジトリの現在の状態を確認しておきましょう。

ここでは git status と git ls-files -s の連携コマンドを実行しました。これで、リポジトリとステージング インデックスの reset_lifecycle_file に保留中の変更があり、そのバージョンが 67cc52710639e5da6b515416fd779d0741e3762e であることがわかりました。これを忘れないようにしながら 1 つ目のコミットに戻ってソフト リセットを実行しましょう。

上のコードでは「ソフト・リセット」を実行するとともに、リポジトリの状態を出力する git status と git ls-files の連携コマンドも呼び出しています。リポジトリの状態の出力を調べるといくつか注目すべき点があります。まず、git status を見ると、reset_lifecycle_file が修正されたことがわかり、それらの修正が後続のコミット用にステージされた変更であることが強調表示されています。次に git ls-files の出力を見ると、ステージング・インデックスは変更されておらず、前からあった SHA 67cc52710639e5da6b515416fd779d0741e3762e がそのままになっていることがわかります。

このリセットによって何が起こったのかをさらに詳しく見るために、git log を調べてみましょう。

ログの出力を見ると、コミット履歴に 1 つだけコミットがあることがわかります。これによって、--soft で何が起きたかがわかりやすくなります。すべての git reset の呼び出しと同様に、リセットで行われる最初の処理はコミット ツリーのリセットです。以前の --hard と --mixed のサンプルでは両方とも HEAD をポイントしておらず、コミット ツリーを過去の状態に戻していませんでした。ソフト リセット中に起こるのはこれがすべてです。

そうなると、git status の結果で修正されたファイルがあった理由がよくわからなくなります。--soft ではステージング インデックスを操作しないため、コミット履歴をたどってステージング インデックスが更新されたことになります。git ls-files-s の出力を見ると reset_lifecycle_file の SHA が変更されていないため、これは間違いありません。本来はツリー間の差分を表示するためのコマンドである git status は「3 つのツリー」の状態を表示しない点をここで繰り返しておきます。このサンプルでは、ステージング インデックスがコミット履歴よりも先の変更になっていてあたかもすでにそれらをステージしたかのような状態になっています。

取り消した直後に新しいコミットを追加すると Git ではローカルな履歴が origin/main から分岐したものして扱われて、リポジトリを同期するために必要なマージ・コミットが他の開発者に対する混乱と作業妨害を引き起こす可能性があります。

重要なことは、git reset ＜commit＞ を使用する際には、結果が思わしくなかったローカルな実験的開発作業を取り消すことが目的であって、公開済みの変更の取り消しをしようとしてはならないと認識することです。公開済みのコミットを訂正する必要がある場合は、その目的の専用コマンド git revert が用意されています。

作業ディレクトリに何の変更も加えずに、指定したファイルをステージングエリアから削除するコマンドです。このコマンドを実行すると、変更を書き込むことなく指定したファイルをアンステージします。

作業ディレクトリに何の変更も加えることなく、ステージング エリアをリセットして直前のコミット時の状態と一致させるコマンドです。このコマンドを実行すると、変更を書き込むことなくすべてのファイルをアンステージし、一度ステージされたスナップショットを初めから再構築できるようになります。

ステージング エリアと作業ディレクトリをリセットして直前のコミット時の状態と一致させるコマンドです。--hard は、変更をアンステージした上でさらに作業ディレクトリ内のすべての変更を元に戻すことを Git に指示するフラグです。言い換えると、これはコミット前のすべての変更を全くなかったものとするコマンドであり、これを使用する場合はローカル マシン上で行った開発作業を本当に破棄していいのか否かを確認する必要があります。

現在のブランチの先端を commit の位置に戻した上でステージング・エリアをその状態と一致するように元に戻しますが、作業ディレクトリのみはそのままにしておきます。＜commit＞ の実行後に行われた変更は作業ディレクトリに保存されており、より変更規模が小さくて整理されたスナップショットを作成してプロジェクト履歴の再コミットを行えます。

現在のブランチの先端を ＜commit＞ の位置に戻した上でステージング・エリアと作業ディレクトリをその状態と一致するように元に戻します。このコマンドを実行すると、コミット前の変更に加えてコミット後に行われたすべてのコミットも全くなかったものとなります。

git reset コマンドはステージされたスナップショットを作成する際によく使われます。次の例では、hello.py と main.py の 2 個のファイルをリポジトリにすでに追加しているものと仮定しています。

ご覧のように、git reset を使用することにより次回のコミットと無関係な変更をアンステージし、そのコミットの目的を明確化できます。

次の例はより高度なユースケースを示します。ここでは実験的開発をしばらく行っていると仮定し、いくつかのスナップショットをコミットした後でそれらをすべて破棄する場合にどうするべきかを示します。

git reset HEAD~2 コマンドは、現在のブランチをコミット 2 回分だけ前に戻すコマンドであり、実質的には最近作成した二つのスナップショットをプロジェクト履歴から削除する働きをします。以前に説明したように、このような reset コマンドの使用対象は未公開のコミットに限るべきです。すでに共有リポジトリにコミットをプッシュしている場合には決して上記の操作を行ってはなりません。

git reset は、git リポジトリの状態に対するローカルの変更を元に戻すための強力なコマンドであることがわかりました。git reset を「git の 3 つのツリー」で操作しました。これらのツリーは、コミット履歴（HEAD）、ステージング・インデックス、作業ディレクトリです。これら 3 つのツリーに対応する 3 つのコマンド・ライン・オプションがあります。オプション --soft、--mixed と --hard は git reset に渡せます。

この記事では、他にもいくつかの git コマンドを活用して取り消しプロセスをわかりやすく説明しました。各コマンドの詳細については、git status、git log、git add、git checkout、git reflog、git revert の各ページを参照してください。