git多层分支架构本身不直接提升高内聚低耦合，但通过分支命名映射模块职责、限制diff范围、分步合并及拦截跨包导入，可有效降低协作导致的耦合恶化风险。
Git 多层分支架构本身不直接提升高内聚低耦合，但它能显著降低因协作导致的耦合恶化风险——前提是分支策略与模块边界对齐。
分支命名必须映射模块职责，否则反而加剧耦合
很多团队用 feature/login 这类命名，看似合理，但一旦 login 涉及 UI、Auth Service、Token Storage 三个包，这个分支就天然承载了跨模块变更。下次改密码逻辑时，开发者可能顺手在同一个分支里动了 UI 和后端，导致隐式依赖固化。
真正有效的做法是让分支名绑定到 packages/ 下的具体模块：
-
feat/packages/ai-sdk/v2-prompt-engine—— 只改 AI 提示引擎，不碰 UI 或 validation -
fix/packages/lib/user-sync—— 仅修复用户同步逻辑，不引入新 UI 组件 -
chore/packages/ui/button-props—— UI 组件内部重构，对外 API 不变
这样每个分支的 diff 范围天然受限，CI 可自动校验：该分支是否只修改了声明的包及其 direct dependencies（通过 pnpm why 或 turbo run build --filter=... 验证）。
main 分支应只接收“模块级”合并，而非“功能级”合并
常见错误是把一个完整功能（比如「支持 OAuth2 登录」）的所有代码一次性合入 main。这会导致 main 上同时出现 UI 修改、Auth Service 增加、validation 规则更新——模块间边界被 merge commit 模糊化。
正确流程是分三步推进：
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
- 先合入
packages/validation的新规则（如isOAuth2Provider），确保其他模块可安全消费 - 再合入
packages/ai-sdk对 token 格式的适配（如果涉及） - 最后合入
apps/web的调用层集成，且只允许 import 已发布的包版本
每一步都需通过 turbo run test --filter=... --no-cache 验证，失败即阻断。这种节奏强制模块接口先行，而不是靠“一起改一起测”来掩盖耦合。
pre-commit hook 必须拦截跨包直接 import
即使有清晰的分支划分，开发者仍可能在 packages/ui 里写 import { User } from '../../lib/src/user.ts'——这是典型的路径耦合，绕过包管理，破坏封装。
建议在 husky + lint-staged 中加入检查：
#!/bin/bash
# .husky/pre-commit
git diff --cached --name-only | grep 'packages/.*\.ts\|\.tsx$' | while read file; do
if grep -q "from '..\/..\/lib\/src" "$file"; then
echo "❌ 检测到非法跨包导入: $file"
exit 1
fi
done
更稳妥的方式是用 eslint-plugin-import 配置 import/no-relative-parent-imports，并配合 pnpm link 阶段的 peer check，确保所有 import 都走 package.json 声明的 dependency。
真正难的不是设计多层分支，而是让每次 commit 都落在模块契约的缝隙里——那里没有共享状态，没有隐式调用，只有明确的输入输出。一旦分支变成“功能容器”，而不是“模块沙盒”，高内聚低耦合就只是文档里的漂亮话。
