回答:
Gitはそれ自体で情報を破棄しません *。すべてのファイルの以前のバージョンはすべて、復元、差分、検査などに常に使用できます。
調整しようとしているのは、個々のファイルの古いバージョンにアクセスするという考え方と、Gitの履歴モデルがツリー全体に焦点を合わせているという事実です。ツリー全体のバージョン管理では、foo.c10個のfoo.c変更前のバージョンと10個のツリー全体の変更前のバージョンを（たとえば）確認するために、もう少し作業が必要です。
# 10 foo.c-changes ago
git show $(git rev-list -n 10 --reverse HEAD -- foo.c | head -1):foo.c
# 10 whole-tree-changes ago
git show HEAD~10:foo.c
ツリー指向の利点は、主にコミットをツリー全体のさまざまな部分に行われた相互依存の変更の単位として表示できることです。一般的に、余分なタイピング（エイリアス、スクリプトなど）とCPU時間を大幅に上回ります。過去のコミットを掘り下げました。
新しいオブジェクト（以前は見えなかった内容のファイルなど）がシステムに入ると、「ルーズオブジェクト」としてプレーン（zlib）圧縮で保存されます。十分な緩いオブジェクトが蓄積されたとき（に基づいてgc.auto構成オプションにまたはユーザーがgit gcまたは下位レベルのパッキングコマンドのいずれかを実行すると、れると、Gitは多数のルーズオブジェクトを1つの「パックファイル」に収集します。
パックファイル内のオブジェクトは、プレーンな圧縮データ（ルーズオブジェクトと同じ、他のオブジェクトにバンドルされたものと同じ）として、または他のオブジェクトに対する圧縮デルタとして保存できます。デルタは、構成可能な深さ（pack.depth）に連結でき、任意の適切なオブジェクトに対して作成できます（pack.windowGitが最適なデルタベースを検索する範囲を制御します。これを行うと、歴史的に無関係なファイルのバージョンをベースとして使用できます。良好なデルタ圧縮）。深さおよびウィンドウサイズの構成がデルタ圧縮エンジンに与える寛容さは、多くの場合、CVSスタイルの単純な1バージョン対次/前バージョンの「差分」圧縮よりも優れたデルタ圧縮をもたらします。
（通常のzlib圧縮と組み合わせた）この積極的なデルタ圧縮は、Gitリポジトリ（完全な履歴と非圧縮作業ツリー）が単一のSVNチェックアウト（非圧縮作業ツリーと初期コピー）よりも多くのスペースを取ることができない場合がよくあります。
Git Community BookのGit StoresオブジェクトとPackfileセクションをご覧ください。また、gitのパックは、オブジェクトのmanページ。
*「履歴を書き換える」とgit resetなどのコマンドを使用してGitにコミットを破棄するように指示できますが、これらの場合でも、Gitは必要な場合に備えて、新しく破棄されたコミットをしばらく「ハング」します。git reflogおよびgit pruneを参照してください。
同じページで読むことができます：
...
そのため、Gitはソースコードツリーの下のどのレベルでもファイルリビジョン関係を明示的に記録しません。
...
プロジェクト全体よりも、単一ファイルの変更履歴を調べる方が少し費用がかかります。特定のファイルに影響を与える変更の履歴を取得するには、Gitはグローバル履歴をたどり、各変更がそのファイルを変更したかどうかを判断する必要があります。ただし、この方法で履歴を調べることにより、Gitは任意のファイルセットへの変更を示す単一の履歴を同じ効率で生成できます。たとえば、ソースツリーのサブディレクトリと関連するグローバルヘッダーファイルは、非常に一般的なケースです。
...
したがって、ファイルの以前のリビジョンに戻って、2つのファイルを比較できます。
gitは実際にはファイルのデルタを保存しますが、ファイルツリー全体のデルタとして保存します。
バージョン間の違いを確認するには、次のいずれかを実行します。
git add実行されてします。git add、実行されたがコミットされていないすべてのファイルとの違いを表示します