git - 我的项目使用了 100 多个 git 子模块，哪个子模块替代方案可以优雅地处理大量存储库

Question

我一直在研究 git 子树和 git 子模块的其他替代方案。我的项目有 100 多个子模块，管理它们非常笨重。

任何人都可以推荐一个工作流程，该工作流程非常适合需要保持同步的大量存储库。

Answer 1

如果您的项目有超过 100 个组件和依赖项的 git 子模块，那么无论您使用哪种方法，它们的管理都将变得笨拙 :-) 我建议寻找尽可能多的脚本和自动化部分的方法。相信我，对大多数人来说，玩弄和链接 git 命令的新鲜感很快就会消失，尤其是在截止日期临近的时候。已经有很好的答案here关于管理 git 子项目的不同方法的比较。

关于工作流程，我将首先将您控制的存储库与非第三方存储库分开。

对于不经常更改的第三方存储库(通过 merge 或上游 PR)，您仍然可以使用子模块。通常，您会将这些子模块指向一些稳定标签的 HEAD。同步它们只是运行(或编写脚本)git submodule update --recursive --remote 的问题。如果可以在包管理工具中指定这些第三方依赖项，如 bundler (for ruby projects) ，这将有助于简化您的子项目管理。

对于您拥有且经常更改的存储库，gitslave或 git-subtree有两种选择，具体取决于您团队的偏好。

gitslave 将 git 操作复用到多个分支中。 IOW，当您进行分支、 merge 、提交、推送、 pull 等操作时，每个命令将依次在父项目和所有从属项目上运行。这要求团队以自上而下的方式工作，从 super 项目开始到从属项目。

gitsubtree 使用 Git 的 subtree merge 功能来实现与子模块类似的效果，通过将文件实际存储在主存储库中并将更改直接 merge 到该存储库。最终结果是一个规范的存储库，可以选择包含所有子项目的历史记录。在某种程度上，这允许团队成员更多地关注他们负责的子树，但需要额外的工作才能 merge 回父树。

作为一名开发人员，我的偏好是在较低的子项目级别工作(做我的 "red, green, refactor" cycle )，并且仅在必要时才接触父项目。但无论您选择自上而下还是自下而上的工作流程，都应尝试在您的分支和 merge 策略中找出重复性容易出错的步骤，并尽可能编写脚本。