私は作業中の小さなプロジェクトでgit-auto-commit-modeを使用しています。その結果、合計で約700件のコミットが行われています。望ましくない副作用として、私は現在gitリポジトリを持っていますが、サイズはわずか1,034kBですが、実際のソースコードファイルの50倍以上である200以上のファイルで構成されています。gitリポジトリのファイルクラッタを減らす
このような混乱を減らす方法はありますか？
私はすでにファイルが古いコミットに関連して、彼らはレポの歴史の中で存在していることを
git repackgit gc --aggressiveを試してみました。つまり、新しいリポジトリを作成し、すべてのファイルを新しいものにコピーして、最初のコミットを行うことです。しかし、あなたの歴史は失われてしまいます。本当に小さなリポジトリが必要な場合は、最も簡単な方法です。
しかし、私の場合、200個のファイルと1MBのディスク容量で問題が発生することはありません。それは何もない。
700は200ファイルのみでコミットします。つまり、それらのコミットのほとんどは空です。 – Gregg
まずはスケールを扱いましょう。あなたは200ファイルが「実際のソースコードの50倍以上」だと言いました。それで、作業ツリーに4つのファイルがあるプロジェクトに基づいて期待を設定しましたか？
これにより、gitはとなり、常にには "たくさんのファイル"があります。
gitのファイルは、プロジェクトの.gitフォルダに保存されているので、本当に混乱しているとは思われません。私はちょうどinit新鮮なレポを編
（あなたが外.gitフォルダをファイルの束を見ている場合は、その後、いくつかの追加情報が。あなたが見て、どこだかについて必要とされている）、そしてそれは14で始まりますすべてのコンテンツがある前にファイルを作成します。 1つのファイルで1つのコミットを追加すると、9つのファイル（refs、reflog、インデックス、3つのヒストリーデータベース内の実際のオブジェクト、およびハウスキーピングの一部）が追加されます。あなたが歴史を構築するとき、最も成長する可能性が高いのはデータベース（.git/objects）です。
ここでは、git がの場合、ファイルの数を減らす「パック」形式でデータベースを格納することができます。それは常にリモートアクセス（プッシュ/フェッチ）のために行われ、時間の経過とともに一般にパックされた表現に「時代遅れ」になります。しかし、頻繁にアクセスされるものへのローカルアクセスの場合は、おそらくゆるやかな表現を使うほうが良いでしょう（これはgitがすべてをパックしようとする試みに協力していない理由です）。
.gitディレクトリのファイル数（通常は何もやりとりしないでください）でハングアップするのではなく、コミット履歴の清潔さについて少し心配しています。
git auto-commitを使用すると、変更をキャプチャできないことを確実にすることができますが、値の低い履歴が作成されます。それを使用する場合は、生成されたコミットを意味的に意味のあるコミット（自動コミットモードを使用しないで行ったソート）に定期的にスクウェアする必要があります。
時間が経つにつれて、ファイル数も減少する可能性があります。私が言ったように、私は本当にそれがポイントの横にあると思う。
これらのファイルがリポジトリにまだ残っている以前のコミットの一部である場合、ファイルは実際には副作用ではありません。彼らは歴史の一部です。 –
あなたはこれらのファイルをまったく扱ってはならないので、gitクライアントを通してのみ、これについて何もする必要はありません。これらの200個のファイルは、リポジトリの履歴、それらの古いバージョンのファイルです。 –
すべての* N *分を自動コミットするのではなく、意味のあるコミットを自分で作成する習慣を身につけて、不要なファイル（およびコミット）を作成することを避けることができます。 （それがgit-auto-commit-modeの場合） – mkrieger1