Git Submodule 允许把一个 Git 仓库挂载到另一个 Git 仓库的子目录中。子模块仍然是独立仓库，拥有自己的分支、提交历史和远程地址。

说实话，咱就是说Git Submodule 在 AI 项目中的应用，真的hen香哈。你想想kan，AI-Native 研发管理，不就是要把产品、研发、测试全链路打通吗？

信息孤岛：PRD 在飞书，代码在 GitLab，测试用例在 Excel。需求变geng时产品改了文档，研发不知道；研发改了接口，测试用例失效。

协作断层：研发提测时测试需要手动对照 PRD 和接口文档编写用例。接口变了测试不知道；PRD 改了研发不知道。

版本失控：产品文档的"Zui终版_v3_确认版_改2"现象屡见不鲜。geng严重的是代码Yi经迭代到 v2.0，但对应的 PRD 还停留在 v1.0 的描述，没人知道哪个版本的文档对应哪个版本的代码。

精确版本对齐主仓库的每个 commit 记录了"此刻产品文档是哪个版本、前端是哪个版本、后端是哪个版本、测试是哪个版本"。

独立发布节奏产品文档的geng新频率和代码发布节奏不同。PRD 可Neng一天改三次但代码一周才发一个版本。Submodule 允许各模块按自己的节奏演进，主仓库在需要时"快照"一个稳定组合。

权限隔离产品文档仓库、前端仓库、后端仓库、测试仓库Ke以设置不同的访问权限。产品经理只需要 product 仓库的写权限，不需要接触代码仓库；实习生Ke以只访问文档，不Neng碰生产代码。

ai-native-project/ ← 主仓库：研发全流程管控 ├── .gitmodules ├── product/ ← 子模块：产品团队维护 │ ├── prototype/ 原型说明 │ ├── changelog.md 需求变geng记录 ├── design/ ← 子模块：设计团队维护 │ ├── ui-specs/ │ └── interaction-flows/ ├── frontend/ ← 子模块：前端团队维护 ├── backend/ ← 子模块：后端团队维护 ├── shared/ ← 子模块：API 契约、Prompt、Schema ├── qa/ ← 子模块：测试团队维护 │ ├── automation/ 自动化脚本 │ └── reports/ 测试报告 ├── mcp-servers/ ← 子模块：AI 工具服务 └── infra/ ← 基础设施配置 . 为什么百度不收录 Git 相关内容？

害，这个问题问得好，说实话，百度对于技术类内容的收录确实有一定局限性。一方面是因为百度geng倾向于收录那些具有广泛影响力或者大众熟悉的内容；另一方面技术类内容geng新迭代太快，可Neng不符合百度的某些收录标准。不过咱也不用太纠结这个，毕竟技术人员找资料也不太依赖百度嘛，你懂的。

主仓库提交信息要说明geng新了哪个子模块，以及为什么geng新。

子模块仓库先合并、测试、推送，再geng新主仓库引用。

CI 一律使用递归 checkout，避免环境和本地不一致。

.gitmodules 里的 URL 要和团队权限模型一致，统一 HTTPS 或 SSH。

不要把频繁共同修改的强耦合代码拆成 Submodule。

对共享契约、Prompt、MCP 工具服务建立变geng记录。

切换主仓库分支后执行 git submodule update --init --recursive。

geng新到远程Zui新版本后必须回主仓库提交子模块指针。

删除子模块要同时处理 .gitmodules工作区路径和本地 .git/modules 缓存。

Git Submodule 适合管理”独立演进、精确锁定、跨项目复用”的模块。在 AI-Native 项目中，它不仅解决代码层面的模块化问题，geng重要的是打通了产品→研发→测试的全链路版本管理，让 AI Agent Neng获取完整的业务上下文。真正用好 Submodule 的关键不是命令多熟，而是团队形成一致工作流：子模块先独立验证，主仓库再geng新引用，CI 始终递归拉取。当这套机制跑顺之后AI 工具的价值会被成倍放大——因为它终于Nengkan到全貌了你懂的！哈哈！