清理Git仓库历史冗余文件的方案是否正确？

1. 排查判断的正确性 #

你的判断完全正确：.composer-cache、vendor、Drupal核心/贡献模块/主题这些都属于依赖或缓存文件，应该通过Composer在部署阶段拉取，根本不需要存入Git仓库历史。9万行记录对应这类文件，说明仓库体积过大的核心原因就是历史中误提交了大量冗余依赖。

2. 清理方案的正确性与补充 #

你的方案整体是标准且正确的，但有几个细节需要完善：

• 前置备份：执行git clone --mirror后，建议再复制一份镜像仓库做备份，避免操作失误导致数据丢失。
• 路径准确性：确认--path参数中的目录和仓库实际结构完全匹配，比如如果历史中存在modules/contrib（不在docroot下）的提交，要补充该路径到命令中。
• 验证升级：除了git rev-list --objects --all，还可以用git count-objects -vH对比清理前后的仓库体积，同时切换到几个关键历史分支，确认目标目录已完全从历史中移除。
• 强制推送的风险：强制推送会彻底重写仓库历史，必须通知所有协作开发者：
  • 放弃本地现有克隆，重新拉取清理后的仓库
  • 确保本地没有未提交的修改，否则会直接丢失
  • 后续所有提交必须基于新的仓库历史，禁止基于旧历史推送

3. 方案是否过于复杂？ #

这个方案一点都不复杂，是Git历史清理的标准流程：

• git filter-repo是官方推荐替代旧工具git filter-branch的工具，操作简洁且稳定，能一次性清理所有分支、标签中的目标文件，比手动删除历史更彻底。
• 步骤都是必要的：镜像克隆避免影响原仓库，路径筛选精准定位冗余文件，验证确保清理效果，强制推送同步云端仓库。

补充后续操作 #

• 清理完成后，务必检查仓库根目录的.gitignore，确保已经正确包含所有需要排除的目录：

  .composer-cache/
  vendor/
  docroot/core/
  docroot/libraries/
  docroot/modules/contrib/
  docroot/themes/contrib/
  web/libraries/
  

• 同步通知所有团队成员仓库历史已重写，指导他们重新克隆仓库，避免后续提交冲突。

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