git多项目管理无银弹，需依协作模式权衡：单仓库多目录（monorepo）适合强耦合、原子提交；子模块适用于需锁定依赖版本的跨团队场景；子树适合单向集成开源库；而完全独立仓库（polyrepo）则是90%中小团队最易维护的默认选择。
Git 本身不内置“多项目管理”概念，所谓目录结构建议，本质是围绕你的真实协作模式、发布节奏和代码耦合度做取舍——没有银弹，只有权衡。
单仓库多目录（Monorepo）适合强耦合场景
当多个子项目共享构建脚本、CI 配置、基础组件或需原子提交时，直接平铺目录最省事。比如：
my-workspace/ ├── frontend/ ├── backend/ ├── shared-utils/ ├── scripts/ └── README.md
这种结构下，git commit 能一次性涵盖跨模块修改，git log 里能看到完整上下文。但要注意：
- 每个子目录应有自己独立的
package.json、build.sh或Makefile，避免隐式依赖根目录 -
.gitignore必须按子目录细化，否则frontend/node_modules和backend/node_modules容易互相污染 - CI 流水线需支持路径级触发（如 GitHub Actions 的
paths:），否则改一行shared-utils就全量构建
子模块（Submodule）适合版本锁定需求
当你需要明确声明“本项目依赖 lib-auth@v2.1.0”，且该库由另一团队维护时，git submodule 是唯一能固化 SHA 的方案。
常见错误是克隆后忘记初始化：
- 克隆主仓库后必须执行
git submodule init && git submodule update - 子模块目录内修改后，要先
git commit子模块，再回到主仓库git add <submodule-path></submodule-path>提交引用更新 -
git status在主仓库中只显示子模块的 SHA 变更，不显示子模块内部文件状态——这点极易误判“没改完”
子树（Subtree）适合单向集成/无协作权限场景
如果你只是定期拉取某个开源库（比如把 lodash 的某分支代码嵌入到私有项目中），又不想让团队成员接触其原始仓库，git subtree 更轻量。
它把外部历史直接 merge 进主仓库，所有操作都在同一工作区完成：
- 添加：
git subtree add --prefix=vendor/lodash https://github.com/lodash/lodash.git es6 - 更新：
git subtree pull --prefix=vendor/lodash https://github.com/lodash/lodash.git es6 - 推送修改回上游？不行——
git subtree push要求你对上游有写权限，且容易混淆历史
性能上，每次 subtree pull 都会重放整个远程分支历史，大仓库下会明显变慢。
完全独立仓库（Polyrepo）是最易维护的默认选择
90% 的中小团队应该从这里起步：每个项目一个仓库，靠文件系统层级组织，不引入任何 Git 内建机制。
例如：
~/projects/ ├── my-app-frontend/ ├── my-app-backend/ └── infra-terraform/
优势在于：
- 权限、CI、分支策略、保护规则可按项目单独配置
- 新人 clone 单个项目即可上手，无心智负担
- 迁移成本最低——哪天想拆成子模块或合并进 monorepo，都还有余地
真正容易被忽略的是「命名一致性」：用 org-name/repo-name 格式统一远程地址，避免混用 git@ 和 https:// 协议；本地目录名与仓库名保持一致，否则 git remote set-url 时容易搞错上下文。
