Git中三个gc配置的区别及分支历史延长配置咨询

核心配置项的区别 #

先明确三个关键配置的作用边界：

• gc.pruneExpire：管控所有无引用的不可达提交的最终清理时间。不管这些提交有没有出现在reflog里，只要超过这个时间，下次GC就会彻底删掉它们。这里的“不可达”指的是没有任何分支、标签、reflog指向的提交。
• gc.reflogExpire：控制reflog里可达提交的过期时间。这些提交是当前分支或其他引用还能直接/间接找到的，reflog只是记录了HEAD曾经指向过它们的历史。过期后reflog条目会被删除，但提交本身因为有引用，不会被清理。
• gc.reflogExpireUnreachable：专门管控reflog里不可达提交的过期时间。这些提交曾经出现在reflog中，但现在已经没有分支、标签指向它们（比如变基后被替换的旧提交）。一旦过期，对应的reflog条目会被删除，这些提交就变成了完全无引用的“垃圾”，等着被gc.pruneExpire触发清理。

简单总结：gc.reflogExpire是给“有用的历史”留reflog记录，gc.reflogExpireUnreachable是给“临时垃圾”设过期时间，gc.pruneExpire是最终的垃圾清理阈值。

关于12.months.ago的合理性 #

这个设置是否合理，取决于你的实际需求：

• 如果团队需要长期保留分支历史做审计、回溯旧版本问题，12个月完全合理，能确保一年内的正常提交不会被误清理。
• 但如果你们经常做变基、清理历史，又不想仓库里堆积太多变基产生的临时提交，建议单独把gc.reflogExpireUnreachable设成更短的时间（比如1.month.ago）。这样变基的垃圾提交会更快进入可清理状态，而正常分支的reflog记录和全局不可达提交的清理时间可以保留12个月，兼顾回溯需求和仓库体积。

适配你需求的配置建议 #

你的目标是保留分支正常过往提交，排除变基产生的临时提交，推荐这样配置：

[gc]
pruneExpire = 12.months.ago
reflogExpire = 12.months.ago
reflogExpireUnreachable = 1.month.ago

这样设置后：

• 分支当前能追溯到的所有历史提交（可达提交），它们的reflog记录会保留12个月，哪怕你之前切换过这些旧版本，记录也不会轻易消失。
• 变基后被替换的旧提交（仅存在于reflog的不可达提交），1个月后reflog条目会被删除，之后这些提交就会被标记为完全不可达，要么等12个月后自动清理，要么你手动执行git gc --prune=now强制清理。

内容的提问来源于stack exchange，提问作者Inigo