临时分支是解耦前后台模块、控制合并节奏的关键缓冲层，用于隔离汇合变更、对齐接口契约，避免直接合并引发大量冲突；创建后需执行三步初始化：拉取后台接口定义并提交更新、再拉取前台代码校验兼容性，冲突本质是契约未对齐的信号，须按规范修复并验证API贯通；销毁前须确保修改已拆分落地至各模块分支且远程分支已清理。
临时分支不是“过渡用完就删”的摆设，而是解耦前后台模块、控制合并节奏的关键缓冲层。直接 git merge feature/backend 到 develop 前台分支，大概率触发大量冲突——尤其当接口契约未冻结、DTO 字段频繁变动时。
为什么不能跳过临时分支直接合入主干
后台模块（如 feature/order-service）和前台模块（如 feature/order-ui）通常由不同团队维护，提交节奏、测试覆盖、发布窗口都不一致。若两者都直接向 develop 合并：
- 后台先合入，前台还没适配新 API，
develop构建直接失败 - 前台先合入，调用不存在的 endpoint，CI 报
404或空指针 - 冲突集中在
api-spec.json、types.ts、mock-data/等契约文件，手工 resolve 效率极低
临时分支（如 integ/order）把这两股变更“隔离汇合”，让契约对齐发生在可控范围内，而不是污染主干。
git checkout -b integ/order origin/develop 之后要立刻做的事
创建临时分支只是起点，真正起作用的是后续三步初始化操作：
- 从后台分支拉取最新接口定义：
git merge --no-commit --squash feature/order-service，只取变更不带提交历史，避免污染临时分支时间线 - 手动校验并提交更新后的
openapi.yaml和生成的src/api/generated/，这是前后台唯一的事实来源 - 再从前台分支拉取：
git merge --no-commit feature/order-ui，此时 Git 能基于已更新的类型定义判断是否兼容——如果OrderItem新增了status_v2字段但前台没消费，git status会明确标出types.ts冲突，而非等到运行时报错
冲突出现在 src/api/generated/ 怎么办
这不是代码写错了，而是契约未对齐的信号。常见情形和应对方式：
-
openapi.yaml中字段名大小写不一致（userIdvsuser_id）→ 统一用 kebab-case 或 PascalCase，后台改 Swagger 注解，前台重新生成，不要手动改生成文件 - 后台新增必填字段，前台未提供默认值 → 在前台代码里补
?? 'default'或调整 DTO 映射逻辑，**不要删掉生成文件里的字段声明** - 生成工具版本不一致（如 openapi-generator v6.2 vs v7.0）→ 临时分支上统一执行
npx @openapitools/openapi-generator-cli@7.0.1 generate -i openapi.yaml -g typescript-axios，确保生成结果可复现
每次解决完这类冲突，立即运行 npm run test:api（或对应契约测试脚本），验证前后端数据流是否真正贯通。这比等 CI 跑完 15 分钟更早暴露问题。
临时分支怎么“安全销毁”
不是简单 git branch -d integ/order 就完事。销毁前必须确认两件事：
- 所有修改已通过
git cherry-pick或git merge --squash拆分落地到各自模块分支（例如后台改的openapi.yaml必须进feature/order-service，前台改的调用逻辑必须进feature/order-ui），否则下次再建临时分支会丢失上下文 - 远程临时分支已清理：
git push origin --delete integ/order，避免他人误切或重复使用旧状态
最容易被忽略的是：临时分支上的 commit hash 不该出现在任何长期分支的提交图谱里。它只是一次性沙盒，连 git log --oneline integ/order 都不该成为日常排查依据。
