Git prune

git log の出力には、2 つのコミットと、hello.txt に加えられた編集に関して、これらのコミットに対応するコミット・メッセージが表示されます。次のステップは、コミットの 1 つを到達不能にすることです。これを行うには、git reset コマンドを使用します。リポジトリの状態を最初のコミットである「added hello.txt」コミットにリセットします。

ここで git log を使用してリポジトリの状態を調べると、コミットが 1 つしかないことがわかります。

デモ リポジトリは、切り離されたコミットを含む状態になりました。"added another line to hello.txt" というメッセージが表示された 2 つ目のコミットは git log 出力には表示されなくなり、切り離されました。コミットが失われたか削除されたかのように見えるかもしれませんが、Git は履歴を削除しないことに関しては非常に厳格です。git checkout を使用して直接アクセスすることで、まだ利用可能であるが切り離されていることを確認できます。

切り離されたコミットをチェックアウトするとき、Git は親切にも、私たちが切り離された状態にあることを説明する詳細なメッセージを表示してくれます。ここでログを調べると、"added another line to hello.txt" のコミットがログ出力に戻っていることを確認できます! これで、リポジトリが切り離されたコミットとともに良好なシミュレーション状態にあることがわかったので、git prune の使用を実行できます。まず、git checkout を使用して main ブランチに戻りましょう。

git checkout 経由で main に戻ると、Git はまたもや親切にも、私たちが切り離されたコミットを後に残そうとしていることを示してくれます。今こそ、切り離されたコミットを prune するときです!次に、git prune を実行しますが、いくつかのオプションを必ず渡す必要があります。--dry-run と --verbose を使用すると、prune するように設定されているが実際には prune されない内容を示す出力が表示されます。

このコマンドはほとんどの場合、空の出力を返します。空の出力は、prune によって実際には何も削除されないことを意味します。なぜこのようになるのでしょうか?このコミットは完全には切り離されていない可能性が高いです。どこかで Git はまだこれに対する参照を維持しています。これは、git prune が git gc の外部においてスタンドアロンで使用されない代表的な例です。これは、Git でデータを完全に失うことがいかに難しいかを示す良い例でもあります。

ほとんどの場合、Git は切り離されたコミットへの参照を reflog に格納しています。これは、git reflog を実行することで調査できます。ここにたどり着くために実行した一連のアクションを説明する出力が表示されるはずです。git reflog の詳細については、git reflog のページをご覧ください。reflog に履歴を保存することに加えて、Git には、切り離されたコミットを prune 実行するタイミングに関する内部的な有効期限があります。繰り返しますが、これらはすべて git gc が処理する実装の詳細であり、git prune はスタンドアロンで使用すべきではありません。

git prune シミュレーションのデモを締めくくるには、reflog をクリアしなければなりません。

上記のコマンドは、現在よりも古い reflog へのすべてのエントリを強制的に期限切れにします。これは容赦のない危険なコマンドなので、一時的なGit ユーザーとしては決して使用する必要がないようにすべきです。このコマンドを実行して、git prune の成功を実証しています。reflog を完全に消去した状態で、git prune を実行できるようになりました。

このコマンドは、上記のような Git SHA オブジェクト参照のリストを出力します。

git prune には、概要セクションで取り上げたオプションの短いリストがあります。

prune は実行しません。単に何を行うかを示す出力が表示されます。

prune によって実行されたすべてのオブジェクトとアクションの出力を表示します。

prune の進行状況を示す出力を表示します。

＜time＞を過ぎたオブジェクトを強制的に期限切れにします。

＜head＞ を指定すると、その head ref のオプションがすべて保持されます。

git remote prune と git fetch --prune の処理内容は同じです。リモート上に存在しないブランチへの参照を削除します。これは、main へのマージ後にリモート ブランチが削除されるチーム ワークフローで作業する場合に非常に適しています。2 番目のコマンド git fetch --prune はリモートに接続し、prune の前に最新のリモート状態をフェッチします。基本的には以下のコマンドの組み合わせです。

汎用的な git prune コマンドはまったく異なります。概要セクションで説明したように、git prune は、ローカルで切り離されたコミットを削除します。

git fetch --prune は、古いブランチをクリーン アップするのに最適なユーティリティです。共有リモート リポジトリに接続し、すべてのリモート ブランチ参照をフェッチします。その後、リモート リポジトリで使用されなくなったリモート参照を削除します。

いいえ、git remote prune origin は、もはや存在しないリモート ブランチへの参照のみを削除します。git はローカルとリモートの両方の参照を保存します。リポジトリには、local/origin と remote/origin の参照コレクションがあります。git remote prune origin は、remote/origin 内の参照のみを prune 実行します。これにより、local/origin 内のローカルの作業が安全に残されます。

git prune コマンドは git gc の子コマンドとして呼び出されることを意図しています。日々のソフトウェア エンジニアリング能力で git prune を呼び出す必要はほとんどありません。git prune の効果を理解するには、他のコマンドが必要です。この記事で使用したコマンドには、git log、git reflog と git checkout などがあります。