我在微信公众号上已经实现了桌游“谁是卧底”发牌器，独立于此项目，又开发了桌游“阿瓦隆”。现在我想将这两个桌游发牌器同时在微信公众号中支持，该如何进行项目管理？
另一个场景，独立开发前后端项目 backend 和 frontend，想要将它们整合在一起实现一键部署，该如何做？
在大型项目中，是选择管理多个子模块，还是在多个子项目基础上抽象出父项目？从架构设计角度考虑，遵循高内聚低耦合的原则，后者显然是更好的选择，能够保证各项目独立开发、互不干扰，而父项目则负责协调各子项目的整合。
我引入了 git submodule 来管理子项目，完美实现“物理隔离，逻辑统一”。这是一个一般用户接触不到的 git 模块，但对于系统架构设计师而言，了解它的存在并在具体项目规划中应用，将发挥重要作用。
虚拟案例：美团“本地生活”的进化之路
为了说明这个问题，我们模拟一个“美团版”的场景。
早期的美团，团购 (tuangou) 和 外卖 (waimai) 是两套人马，独立开发和运营。随着业务版图扩张，公司成立了 local-life (本地生活) 团队，目标是打造一个统一门户，汇聚成为顶流App，占据应用商店排行榜。
核心诉求：
- 统一入口：用户登录一个 App，就能切换团购和外卖。
- 统一鉴权：别让用户在外卖里登录一次，进团购还得再登一次。
- 独立性：外卖团队今天想发版，不能因为团购团队的代码没写完就被卡住。
破局方案：成立新的父项目 local-life。它不生产业务代码，它只是业务的“搬运工”。通过 git submodule 将 tuangou 和 waimai 引入，变成自己的子文件夹。
Git Submodule 实战指令
更多命令字典，推荐菜鸟教程：www.runoob.com/git/git-sub…
先快速查看git submodule的指令手册git submodule --help
git submodule [--quiet] [--cached]
git submodule [--quiet] add [<options>] [--] <repository> [<path>]
git submodule [--quiet] status [--cached] [--recursive] [--] [<path>...]
git submodule [--quiet] init [--] [<path>...]
git submodule [--quiet] deinit [-f|--force] (--all|[--] <path>...)
git submodule [--quiet] update [<options>] [--] [<path>...]
git submodule [--quiet] set-branch [<options>] [--] <path>
git submodule [--quiet] set-url [--] <path> <newurl>
git submodule [--quiet] summary [<options>] [--] [<path>...]
git submodule [--quiet] foreach [--recursive] <command>
git submodule [--quiet] sync [--recursive] [--] [<path>...]
git submodule [--quiet] absorbgitdirs [--] [<path>...]
与复杂的git指令一样，起步阶段只需要关注这几条“瑞士军刀”命令：
添加子模块
git submodule add https://github.com/meituan/tuangou.git
这会在根目录生成一个 .gitmodules 文件，这个文件相当于父项目的“户口本”，记录了子模块是谁、在哪。
一键拉取
克隆整个父项目，子模块默认是空的，可以使用--recursive递归拉取子项目
git clone --recursive https://github.com/meituan/meituan.git`
如果在克隆父项目时，没有指定--recursive，可以使用指令
git submodule update --init --recursive
同步更新
当子项目团队更新了代码，父项目想引用最新的版本：
git submodule update --remote
当然，父项目中也可以提交对子代码的更新，在 JetBrains 或 VSCode 等 IDE 中的 git 插件模块，默认允许管理所有的 git 仓库。
在父项目中直接修改子模块代码，是不被推荐的，这不利于父子项目治理。
团队治理
项目多了，管理不能乱。在父子项目架构下，职责划分要像切菜一样清晰：
父项目团队（物业公司）
不关心外卖里卖的是炸鸡还是汉堡，他们负责：
- 稳定性与运营，确保 App 平稳运行。
- 公共资源：统一的鉴权逻辑、统一的 UI 组件库。
- 流程约束：制定子项目入驻的规范（比如接口文档怎么写）。
子项目团队（业主/商户）
业务专家，负责：
- 快速迭代：今天加个优惠券，明天改个排版，只要在子仓库折腾就行，不影响别人。
- 质量负责：自己负责的业务模块，出了 Bug 自己修。
治理手段
版本锚定：父项目始终记录子项目的一个“特定版本（Commit ID）”，只有经过测试的子项目版本，才会被父项目“转正”更新。
总结
Submodule 最大的优势在于解耦，它允许各团队保留独立的 Git 权限和不同的开发节奏。如果你也面临多团队协作、统一平台构建的难题，不妨试试 Git Submodule。它是目前运维架构中，性价比极高的“降熵”工具。
关注微信公众号，获取运维资讯
如果此篇文章对你有所帮助，感谢你的点赞与收藏，也欢迎在评论区友好交流。
微信搜索关注公众号：持续运维
参考
- 菜鸟教程 git submodule，www.runoob.com/git/git-sub…
