monorepo 中多团队开发分支隔离需通过目录级权限、前缀式分支命名（如team-a/feat/button-v2）和ci拦截三者组合实现；每个子包在package.json中声明"owners"字段，ci校验pr修改者是否在归属团队列表内，非owner提交自动阻断；按影响范围决定合并策略：仅应用层改动可直推main，涉及包接口变更须经changeset、版本升级及下游e2e验证。
Monorepo 里怎么隔离多团队的开发分支？
不能靠 Git 分支本身做团队隔离——main、dev 这类通用分支是共享的，团队 A 在 feature/login 上改组件库，团队 B 同时在 feature/dashboard 上改管理后台，两个分支都可能修改 packages/ui，一旦 push 到远端，就天然存在冲突风险。
真正可行的隔离方式是「目录级权限 + 分支命名约定 + CI 拦截」三者组合：
- 用
git hooks或 CI 脚本校验 PR 的路径变更范围，比如团队 C 只能提交到apps/crm/和packages/crm-utils/，其他路径直接拒绝合并 - 强制使用前缀式分支名，如
team-a/feat/button-v2、team-b/fix/auth-timeout，方便自动化识别归属 - 不依赖 Git 内置权限（GitHub/GitLab 的 branch protection 对单仓多团队意义有限），而是靠
nx affected或turborepo run检查实际影响范围，只跑被改动目录相关的测试和构建
多个团队同时改同一个包，怎么避免互相覆盖？
核心矛盾不是“谁先合”，而是“谁有权改”。Monorepo 里没有天然的包所有权，必须显式定义。
推荐做法是把 packages/ 下每个子包的 package.json 加一个 "owners" 字段：
{
"name": "@org/ui",
"version": "1.2.0",
"owners": ["team-design", "team-core"]
}
然后在 CI 中集成检查逻辑：
- PR 修改了
packages/ui，但作者不在owners列表里 → 自动 comment 提醒并阻断合并 - 若需跨团队协作修改，必须由 owner 团队发起
changeset提议，或通过 RFC issue 达成共识后再操作 - 避免用 “所有人可写” 的宽松策略，否则
packages/utils很快变成没人敢动的“公共厕所”
按需合并：哪些变更必须合入 main，哪些可以暂存？
Monorepo 不等于所有改动都要立刻进 main。关键判断标准是「是否破坏下游消费方」。
- 只改
apps/mobile且不涉及任何packages/→ 可以走短生命周期分支，测试通过后直推main - 修改
packages/form并导出新 API → 必须生成changeset，触发版本 bump，并确保所有引用它的apps/*都通过 e2e 测试才能合入 - 重构
packages/core的内部实现但保持接口不变 → 可先合入main，再用turborepo run test --filter=...验证影响范围，无需等所有应用同步升级
真正容易被忽略的点是：main 分支不是“稳定线”，而是“可验证线”。它上面的代码未必能直接部署，但必须能被所有下游项目在本地 pnpm link 后跑通基础流程。
