我一直在我正在处理的一个小项目上使用git-auto-commit-mode，到目前为止总共有700次提交。作为一个不受欢迎的副作用，我现在有一个git存储库，其大小只有1,034kB，但包含200多个文件 - 比实际源代码文件多50倍。
有没有办法减少这种混乱？
我已经尝试了
git repack git gc --aggressive 答案 0 :(得分：1)
该文件与旧提交有关，它们存在于回购历史中。因此，您可以做的是创建一个新的存储库并将所有文件复制到一个新文件并进行初始提交。但是你的历史遗失了。如果你真的想要一个更小的存储库，这是最简单的方法。
但在你的情况下，我看不到200个文件的问题......和1MB的磁盘空间。这没什么。
答案 1 :(得分：0)
首先让我们解决规模问题。你说200个文件是“实际源代码的50倍” - 所以你根据工作树中有4个文件的项目来设置你的期望，对吗？
通过这个衡量标准，git 总是将拥有“大量文件”。
现在，文件git维护在项目的.git文件夹中，所以我并不认为它构成了混乱。 （如果您在.git文件夹中看到在之外的一堆文件，则需要一些关于您所看到的内容以及位置的其他信息。）
我只是init编了一个新的回购，它在有任何内容之前以14个文件开头。使用单个文件添加单个提交会添加另外9个文件（refs，reflogs，索引，历史数据库中的3个实际对象以及一些管理材料）。在构建历史记录时，可能增长最多的是数据库（.git/objects）。
现在你提到的命令已经尝试了...那些暗示git 可以以“打包”格式存储数据库，这减少了文件的数量。这总是用于远程访问（推送/获取），并且随着时间的推移，历史将通常“老化”为打包表示。但是对于本地访问经常访问的东西，你可能最好使用松散的表示（这就是为什么git不会与你试图打包所有东西合作）。
而不是挂在.git目录中的文件数量（通常不应该与之交互），我会担心提交历史记录的清洁程度。
使用git自动提交可以确保您永远不会捕获更改，但它会创建一个低值历史记录。如果你打算使用它，那么你需要定期将生成的提交压缩到语义上有意义的提交（你没有自动提交模式的那种提交）。
随着时间的推移，这可能会减少文件数量;但就像我说的那样，我真的认为这不是重点。