Git 子模块 vs 多仓管理：小型团队怎么选

团队仓库只有一两个的时候，怎么组织代码似乎不是问题。可一旦出现「公共组件库 + 多个业务项目」的结构，每个小团队都会面临同一个选择题：把公共代码用 Git submodule 挂进业务仓，还是干脆拆成多个独立仓库，靠包管理器引用？这两种方案我都在项目里用过，说说各自的适用场景。先说子模块。submodule 的思路很直接：主仓里存一个指针，指向子仓的某个 commit。好处是「锁定版本」非常精确，主仓永远知道自己在用哪个版本的公共代码，回滚、复现环境都很可靠。对嵌入式、C/C++ 这类没有成熟包管理生态的项目，子模块几乎是唯一合理的选择。但它的日常体验有几个著名的坑。第一，clone 之后默认是空的，必须记得 --recurse-submodules，忘了就是一串空目录；第二，子模块更新后主仓里的指针不会自动跟，团队里经常出现「你升了、他没升」的版本漂移；第三，在子模块目录里切分支、改代码再提交，很容易把指针指到一个只存在于自己本地的 commit，别人一拉就断。再说多仓。把公共代码发成内部包（npm、pip、Maven、Go module 都支持私有源），业务仓像用普通三方库一样引用它。这条路把「版本关系」交给了包管理器，语义化版本加锁文件就能解决大部分一致性问题，开发者的心智负担明显更低，CI 也简单：每个仓独立构建、独立测试。代价是发布流程的存在感很强——改一行公共代码，要走「提交、发版、业务侧升级依赖」三个仓的动作，热修时显得笨重；而且跨仓的原子性变更（公共接口和调用方必须同时改）需要靠版本约束和发布纪律来兜底。我的建议按团队规模和发布频率来分：如果公共代码变更极少、下游项目对版本极其敏感（比如硬件配套代码），用 submodule，锁定带来的确定性值得忍受它的别扭；如果公共库迭代活跃、一周要发好几个版本，果断多仓加内部包源，让包管理器干它擅长的事；介于两者之间的小团队，可以先多仓起步，等真正出现「必须精确锁定」的需求再引入子模块，反向迁移的成本要小得多。最后提一句纪律问题：无论选哪条路，都要在 README 里写清楚「公共代码变更后下游如何跟进」的约定。工具选型解决一半问题，另一半靠的是团队对流程的共识。