我最近发现/etc/.git/磁盘空间达到了大约 30G [原文如此！]。此存储库仅适用于etckeeper.我对 git 有一点经验。
我想出了两个解决方案：
- 显而易见，删除旧的提交（一年以上）。但是 bcommits 可能在某种程度上是依赖的吗？
git gc是另一个。我以前从来没有做过这个，只读过git help gc。据说鼓励使用此命令。据我了解，只有内部结构（和一些垃圾收集）被更改和克隆，在没有任何更改的情况下仍然可以进行提交和提交，并且数据不受影响？
在这种情况下，什么是好的做法？
答案1
其想法git gc是删除不再可访问的对象。由于etckeeper只是添加提交，这可能不会有太大帮助。但这也没有什么坏处，也许通过重新包装可以节省一点空间。
/etc/您过去可能设法拥有一些巨大的文件，现在它仍然存在于您的 git 历史记录中。要么扔掉所有的 git 历史记录。 （如果是 /etc/，这可能是一个选项。）或者尝试从历史记录中删除这个大文件。看看BFG 回购清理器。
答案2
您的存储库可能包含历史记录中的一些大文件。du -hs请问你能给出 的输出吗？这将澄清这些文件是否位于当前目录中，因此位于 gitkeeper git 存储库/etc的 HEAD 中。/etc一种更具交互性的方法是使用方便的工具ncdu。如果当前目录下有不需要的大文件，/etc直接删除即可。但是，我将假设在这个答案的其余部分中，它们大部分位于历史记录中，而不是在当前/etc目录中。
一个选项是重写 git 存储库以删除这些大文件。这将分两步进行。
- 识别大文件。
- 重写存储库以删除这些文件。
请注意，存储库的 HEAD 将保持不变，因此不会影响您的/etc目录。
我最近在外围参与了一个 git 存储库（不是我自己的）的工作。如果你想了解更多细节，我可以尝试挖掘它们。然而，那里使用的方法非常手动和 DIY。在参与的人员中，包括我自己在内，没有一个人是 git 专家。因此，如果有现有的工具可以自动执行此操作，那可能会更好。
答案3
巨大的存储库位于 /etc/.git 中。如果您不需要保留该历史记录，则可以通过以下方法完全删除该 git 存储库：
1）使用“rm -rf .git”手动删除 .git 目录- 我认为这是一个空间不足的紧急选项。我不知道etckeeper是否怪异或者什么，但这肯定会解决这个问题。堆栈溢出参考：https://stackoverflow.com/questions/1213430/how-to-complete-delete-a-git-repository-created-with-init
2）另一种选择是使用 etckeeper 本身做同样的事情。来自 etckeeper 网站：
“该存储库中记录的历史记录是否是您需要保留的内容，或者您是否可以将其删除并将当前的 /etc 检查到新的 VCS 中？
对于后一种情况，您只需执行三个步骤：
etckeeper uninit # 删除 /etc/.git！
vim /etc/etckeeper/etckeeper.conf
etckeeper init
参考：https://github.com/joeyh/etckeeper
您不必通过编辑 etckeeper.conf 文件来更改 VCS。如果您不理会 etckeeper VCS 并执行“etckeeper init”，它只会使用 git 以及 /etc 目录的当前状态启动一个新的存储库。
这是来自 Turnkey Linux 的另一个参考：
维护者接受的答案：“运行：etckeeper uninit -f；etckeeper init”
我的空间快用完了。我刚刚执行了上述步骤，删除了 15 GB 不需要的历史记录。我认为 etckeeper 非常适合持续监控 /etc 目录，但我不需要 2 年的历史记录。
答案4
我知道是什么导致了这个问题。结果发现 SAMBA4/AD ldb 位于/etc/;该文件大约有 500MB，如果数据库中的某些内容发生更改，git 会生成整个文件的快照。该仓库已有大约一年的历史，所以它的大小是合适的；）
有用的提示：
- Git repo 是独立的，所以简单的
cp -r(scp, ... ) 是可行的。 - Git 内部是一堆 blob（大部分），因此压缩并没有多大帮助。
git gc检查不可用的对象，有时会压缩内容，但由于前面的一点，它在节省磁盘空间方面并不是那么有效。
因此，解决方案只是备份存储库（存档或clone最新版本），然后将其删除并调用/etc/：
etckeeper init
etckeeper commit "First message in new repo."
也许还可以.gitignore根据您的需求进行定制。感谢您的回答，两者都有帮助且正确。