monorepo中传统git flow失效，因其语义错配——一个仓库≠一个发布单元；推荐基于包边界的“分层分支”策略，按变更影响域隔离，结合turbo/nx自动识别修改范围，通过结构化约束（如publishconfig校验、.gitattributes导出控制、pre-push拦截）实现自动化治理。
Monorepo 下没有“标准分支策略”，强行套用 main/develop 会迅速失控——因为一次提交可能横跨 3 个应用、2 个共享包和 1 套 CI 配置，而每个包的发布节奏、稳定性要求、测试覆盖度完全不同。
为什么传统 Git Flow 在 Monorepo 中失效
不是工具不支持，而是语义错配。Git Flow 假设“一个仓库 = 一个可独立发布的单元”，但 Monorepo 里 apps/web 和 packages/ui 的变更生命周期天然不同：
-
apps/web每周发版，需严格控制main上的 commit 质量，但允许高频feature/*分支合并 -
packages/ui修改影响所有应用，必须经过全量视觉回归 + 类型检查，不能靠“合并到 develop 再测”兜底 -
scripts/deploy的修复必须原子性同步到所有环境，但又不能卡住apps/admin的紧急 hotfix 流程
直接复用 git flow init 生成的分支模型，会导致 PR 审查粒度失焦、CI 失败定位困难、发布回滚成本指数上升。
推荐：基于包（package）边界的“分层分支”策略
核心原则：分支不是按“功能”或“阶段”切分，而是按“变更影响域”隔离。Monorepo 工具链（如 turborepo、nx）能自动识别哪些包被修改，这是策略落地的技术基础。
- 所有开发从
main拉出feat/<package-name>/<short-desc></short-desc></package-name>，例如feat/ui/button-variant或feat/apps/mobile-login-flow；禁止无包前缀的feat/* - CI 触发时，只运行被修改包及其依赖链上的测试（
turbo run test --filter=ui,apps/web），跳过未变动模块 - 发布分支不叫
release/*，而是publish/<package-scope>@<version></version></package-scope>，例如publish/@myorg/ui@2.4.1；该分支仅包含该包的 diff，由自动化脚本从maincherry-pick 生成 -
main始终保持可构建、可测试，但不保证“可发布”——它承载的是跨包集成验证，不是生产就绪快照
如何避免 main 变成“不可描述的混沌状态”
这是 Monorepo 分支管理中最容易被忽略的陷阱：没人敢删 main 上的临时调试代码，因为不知道谁在依赖它。解决方案不是靠流程约束，而是靠结构强制：
- 根目录
package.json中禁用"private": false，所有子包必须显式声明"private": true或"publishConfig"，否则 CI 直接拒绝合入main - 在
.gitattributes中标记apps/** export-ignore和packages/** export-ignore，确保git archive不会意外打包出非发布单元 - 每天凌晨执行
turbo run lint --no-cache --filter="!shared/**"，强制所有非shared/包不得 importshared/utils以外的跨域路径——把架构约束编译进分支准入检查
真正的分支治理不靠命名规范，而靠让“错误操作无法完成”。当 git push origin main 因缺少 publishConfig 被 pre-push hook 拦下时，团队才开始真正理解 Monorepo 的边界在哪里。
