关于Git Subtree的技术问询：是否应清理父仓库提交历史中的子仓库提交记录？

嘿，很高兴看到你已经上手Git Subtree的基础用法了！针对你的几个疑问，我来一步步拆解：

1. 将子项目提交记录保留在父仓库历史中属于最佳实践吗？ #

这个问题没有绝对的标准答案，得看你的团队协作模式和项目需求：

• 如果是需要紧密关联的场景：比如父项目和子项目同属一个团队维护，或者父项目的功能迭代高度依赖子项目的特定修改，保留这些提交其实是最佳实践。它能让团队清晰追踪到父项目与子项目的版本对应关系，出问题时能快速回溯到“父项目用了子项目的哪次变更”。
• 如果子项目是独立维护的第三方依赖：比如你只是把子项目当作一个现成组件引入，不需要追踪它的每一次变更细节，那保留这些提交反而会让父仓库的提交历史变得臃肿杂乱，增加后续排查问题的成本，这时候就不算最佳实践。

2. 为什么仅包含子项目代码变更的提交要留在父仓库？ #

这其实是Git Subtree的工作机制决定的：
Git Subtree本质是把子项目的代码合并到父仓库的指定目录下，而非像Submodule那样只记录版本引用。当你同步子项目的上游变更，或者在父仓库里对子项目做本地修改时，Git会生成对应的提交——这些提交的核心作用是记录父仓库当前所依赖的子项目状态。
举个例子：如果某天父项目突然出现bug，你可以通过这些提交快速定位到“当时是不是同步了子项目的某次变更才引发的问题”，或者确认“当前父项目里的子项目代码有没有做过本地定制”。

3. 若不应保留，清理这些提交记录的最佳方式是什么？ #

如果确定要清理父仓库中仅涉及子项目的提交，推荐使用git filter-repo（官方已经弃用了旧的git filter-branch，前者更安全高效），具体步骤如下：

1. 先备份仓库：重写历史是不可逆操作，一定要先把当前仓库备份到本地或者其他远程地址。
2. 执行清理命令：假设你的子项目目录是sub-project，运行以下命令移除所有仅涉及该目录的提交：

   git filter-repo --path sub-project --invert-paths
   

   这个命令会重写整个仓库的提交历史，移除所有和sub-project目录相关的变更记录。
3. 同步到远程仓库：因为历史被重写，需要强制推送到远程仓库（注意提前通知团队成员，让他们先提交本地修改，然后重新克隆仓库）：

   git push origin main --force
   

另外，如果之后不想再让子项目提交污染父仓库历史，也可以考虑改用Git Submodule——它只在父仓库中记录子项目的版本哈希，不会把子项目的提交历史合并进来，但Submodule的使用复杂度会比Subtree高一些，需要团队统一学习用法。

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