コミットや変更を元に戻す

コミットごとに一意の SHA-1 識別ハッシュがあります。この ID を使用して、コミットされたタイムラインを移動したり、コミットを再確認したりします。既定では、git log は現在選択されているブランチのコミットのみを表示します。表示したいコミットが別のブランチのものであることは十分に考えられます。git log --branches=* を実行すると、すべてのブランチのすべてのコミットが表示されます。git branch コマンドは、他のブランチの表示や移動に使用します。git branch -a コマンドを実行すると、既知の全ブランチ名が一覧表示されます。表示されたブランチ名のいずれかを git log で使用すると、そのブランチのログを作成できます。

確認する履歴にコミット参照がある場合は、git checkout コマンドを利用してそのコミットを確認できます。git checkout によって、開発マシン上に保存されたスナップショットを簡単に「ロード」できます。一般的な開発プロジェクトの進行中に HEAD は通常 main ブランチまたはその他のローカル ブランチを指しますが、過去のコミットをチェック アウトすると HEAD はブランチではなくコミットを直接指すようになります。この状態を「detached HEAD」状態と呼びます。図で説明すると次のようになります。

この例では、常識外れの開発を実験的に開始したものの、それを保存しておくべきか否かについて判断ができないものと仮定します。そしてこの判断の参考とするため、実験的開発を開始する前のプロジェクトの状態を確認するとします。最初に、確認するバージョンのIDを知る必要があります。

コミットを「元に戻す」には、いくつかの異なる技術戦略があります。以下のサンプルでは、次のようなコミット履歴があると仮定します。

git checkout コマンドを使用すると、以前のコミット a1e8fb5, をチェックアウトして、コミットがおかしくなる前の状態にリポジトリを戻せます。特定のコミットをチェックアウトすると、リポジトリは「detached HEAD」状態になります。これはブランチ上で作業していないことを意味します。detached 状態で作成されたコミットは、ブランチを確立されたブランチに戻すよう変更したときにどれも孤立した状態になります。孤立したコミットは、Git のガベージ コレクションの削除対象となります。ガベージ コレクションは設定されたインターバルで実行され、孤立したコミットは完全に削除されます。孤立したコミットがガベージ コレクションの対象となることを防ぐには、必ずブランチで作業する必要があります。

detached HEAD 状態から、git checkout -b new_branch_without_crazy_commit を実行できます。この操作により、new_branch_without_crazy_commit というブランチが新規作成され、この状態に切り替わります。リポジトリは新しい履歴タイムライン上にあります。このタイムラインにコミット 872fa7e は存在しません。この時点で、「元に戻し終わった」と見なし、コミット 872fa7e がないこの新しいブランチで作業を継続できます。残念ながら、以前のブランチ、おそらくは main ブランチが必要な場合、この元に戻す戦略は適していません。他の「元に戻す」戦略を見ていきましょう。詳しい情報や例については、git checkout の説明を参照してください。

元のコミット履歴のサンプルに戻ったと仮定しましょう。872fa7e コミットを含む履歴。今回は打ち消す「元に戻す」を試してみましょう。git revert HEAD を実行すると、Git は最後のコミットの逆で新しいコミットを作成します。これにより、現在のブランチ履歴に新しいコミットが追加され、次のようになります。

この元に戻す戦略で、作業サンプルを続けます。git reset は複数の用途と機能を備えた汎用性のあるコマンドです。git reset --hard a1e8fb5 を呼び出すと、コミット履歴はその指定されたコミットにリセットされます。git log でコミット履歴を調べると、次のようになります。

前のセクションでは、コミットを元に戻すためのさまざまな戦略について説明しました。これらの戦略はすべて、直前に実行したコミットにも適用できます。ただし、場合によっては、直前のコミットの削除やリセットが不要なこともあります。おそらくコミットが不完全だっただけです。そのような場合は、直前のコミットを修正します。作業ディレクトリでさらに変更を加え、git add を使用してコミットのためにステージングしたら、git commit --amend を実行します。こうすることで、Git は設定されたシステム・エディターを起動し、直前のコミット・メッセージを変更できるようにします。新しい変更は、修正されたコミットに追加されます。

リポジトリの履歴にコミットするまで、変更はステージング・インデックスと作業ディレクトリに保管されています。これら 2 つのエリア内の変更は元に戻せます。ステージング・インデックスと作業ディレクトリは、内部的な Git の状態管理メカニズムです。これら 2 つのメカニズムの仕組みについては、git reset ページにある詳しい説明を参照してください。

通常、作業ディレクトリはローカルのファイル・システムと同期しています。作業ディレクトリの変更を元に戻すには、使い慣れたエディターでふだん行うようにファイルを編集します。Git には、作業ディレクトリの管理に役立つユーティリティがいくつか用意されています。git clean コマンドは、作業ディレクトリへの変更を元に戻すのに便利なユーティリティです。さらに、git reset を --mixed または --hard オプションを使用して実行すると、作業ディレクトリにリセットが適用されます。

git add コマンドは、ステージング・インデックスに変更を追加するために使用します。ステージング・インデックスの変更を元に戻すには、主に git reset を使用します。--mixed を使用したリセットは、保留中の変更をステージング・インデックスから作業ディレクトリに戻します。

リモートリポジトリを使ってチームで作業する場合、変更を元に戻すときにはさらに考慮が必要です。通常、git reset は「ローカル」で元に戻す方法と見なすべきです。プライベートブランチへの変更を元に戻す場合は、リセットの使用をお勧めします。リセットでは、他の開発者が作業している可能性がある他のブランチからコミットの取り消しを切り離すことができます。共有ブランチでリセットを実行した後、git push を使ってそのブランチをリモートでプッシュすると、問題が生じます。この場合、足りないコミットがあるため、プッシュしようとしているブランチはリモートブランチより古いとして、Git はプッシュをブロックします。

共有履歴を元に戻す方法としては、git revert をお勧めします。打ち消しは共有履歴からコミットを削除することは一切ないため、リセットよりも安全です。打ち消しは元に戻すコミットを保持したまま、削除するコミットを逆向きにする新しいコミットを作成します。離れた場所にいる開発者がブランチをプルして、やり直すコミットを元に戻した新しい打ち消しコミットを受け取れるため、この方法は共有リモート コラボレーションにより安全な選択肢です。

ここでは、Git で行った作業を取り消すための戦略の概要を取り上げました。Git プロジェクトを「元に戻す」方法は 1 つではないことを覚えておいてください。このページで説明したトピックのほとんどは、関連する Git コマンド別のページでさらに詳しく説明されています。最もよく使われている「元に戻す」ツールは、git checkout、git revert、git reset です。重要なポイントは以下のとおりです。

• 変更がコミットされると、通常は永続的です
• git checkout を使用してコミット履歴を移動し確認します。
• git revert は、共有のパブリックな変更を元に戻すときに使用するのが最適
• git reset は、ローカルのプライベートな変更を元に戻すときに使用するのが最適

主な元に戻すコマンドに加えて、他の Git ユーティリティを見てみましょう。失われたコミットを探すための git log、コミットされていない変更を元に戻すための git clean、ステージング・インデックスを修正するための git add があります。

これらのコマンドは、それぞれ詳しく説明されています。ここで説明した個々のコマンドの詳細については、対応するリンク先を参照してください。