Gitが処理できるファイルの数を尋ねられたときのLinus Torvaldsの言葉を引用すると、2007 年の Google での技術講演(43:09):
…Git はコンテンツを追跡します。単一のファイルを追跡することはありません。Git でファイルを追跡することはできません。単一のファイルを持つプロジェクトを追跡することはできますが、プロジェクトに単一のファイルがある場合は、もちろんそうすることができます。しかし、10,000 個のファイルを追跡する場合、Git はそれらを個別のファイルとして認識することはありません。Git はすべてを完全なコンテンツとして認識します。Git のすべての履歴は、プロジェクト全体の履歴に基づいています…
（トランスクリプトここ。
しかし、実際にGitの本では、まず Git 内のファイルは追跡可能か追跡不可かがわかります。さらに、Git エクスペリエンス全体がファイルのバージョン管理に向いているように思えます。 または を使用すると、git diff出力git statusはファイルごとに表示されます。 を使用する場合は、git addファイルごとに選択することもできます。ファイルごとに履歴を確認することもでき、非常に高速です。
この記述はどのように解釈すべきでしょうか? ファイル追跡に関して、Git は CVS などの他のソース管理システムとどう違うのでしょうか?
ベストアンサー1
CVSでは、履歴はファイルごとに追跡されていました。ブランチは、それぞれ独自のバージョン番号を持つさまざまなリビジョンを持つさまざまなファイルで構成されていました。CVSはRCS（リビジョン管理システム）、同様の方法で個々のファイルを追跡しました。
一方、Git はプロジェクト全体の状態のスナップショットを取得します。ファイルは個別に追跡およびバージョン管理されません。リポジトリ内のリビジョンは、1 つのファイルではなく、プロジェクト全体の状態を参照します。
Git がファイルを追跡するとは、単にそのファイルがプロジェクトの履歴に含まれることを意味します。Linus の講演は、Git のコンテキストでのファイル追跡について言及したのではなく、CVS および RCS モデルと Git で使用されるスナップショットベースのモデルを対比するものでした。