一、分支策略服务于交付节奏
Git 分支策略没有唯一标准，关键是匹配团队规模、发布频率和风险控制。小团队高频发布可以使用 trunk-based development，大团队或多版本维护可能需要 release 分支。策略越复杂，协作成本越高，必须有明确收益。
| 策略 | 特点 | 适合场景 |
|---|---|---|
| 主干开发 | 分支短、集成快 | 持续交付 |
| Git Flow | 分支角色多 | 版本周期长 |
| Release分支 | 支持补丁维护 | 多版本并行 |
| Feature分支 | 隔离开发 | 中小需求 |
无论选择哪种，主分支都应保持可构建、可测试、可发布。不能让 main 长期处于不可用状态。
二、分支命名与提交规范
分支命名要让人一眼看出目的，例如feature/order-export、fix/login-timeout、release/2026-07-08。提交信息应描述意图，而不是重复文件变化。
gitcheckout-bfeature/order-exportgitadd.gitcommit-m"feat: add order export job"gitpush-uorigin feature/order-export团队可以采用 Conventional Commits，但不要把规范变成形式主义。好的提交应该小而完整，能通过测试，必要时可以单独回滚。把多个无关修改塞进一个提交，会让 review、定位和回滚都变困难。
三、Pull Request要控制大小
PR 是协作质量的关键入口。一个 PR 最好只解决一个问题，并附带背景、变更点、测试方式和风险说明。超过几千行的 PR 通常很难被认真 review，应该拆成准备性改动、核心逻辑和清理工作。
背景：订单列表需要导出最近三个月数据 变更：新增导出任务、权限校验、下载接口 测试：单测通过，本地验证 1 万行导出 风险：大查询可能影响数据库，已加分页游标保护分支也很重要。main 分支应要求 CI 通过、至少一名 reviewer、禁止直接 push。对于高风险仓库，可以要求线性历史或合并队列，避免多个 PR 单独通过但合并后冲突。
四、发布与回滚要可追溯
分支策略最终要落到发布。每次发布应能追踪到提交、PR、构建号和制品版本。线上问题发生时，团队要能快速判断是哪个变更引入，并选择修复前进还是回滚。
gittag-av1.8.3-m"release v1.8.3"gitlog--onelinev1.8.2..v1.8.3gitrevert<bad_commit>实践建议：保持分支短生命周期，尽早合并，依赖 feature flag 隔离未完成能力；CI 是合并门禁，不是发布后补救；紧急修复走清晰的 hotfix 流程，并把修复同步回主分支。好的 Git 协作不是分支图漂亮，而是变更可审查、集成可验证、问题可回退。
团队还应约定冲突处理方式。公共模块变更要尽早通知相关同学，数据库迁移、接口契约和配置改动应在 PR 中明确标注。不要长期保留无人维护的功能分支，它们会积累冲突并偏离主干。对于大型改造，可以先合并无行为变化的重构，再逐步切换调用方。分支策略的目标是降低协作摩擦，让代码持续靠近可发布状态。
📌 本文是《工程化交付实战》系列，持续更新，关注不迷路。
👉 下一篇：《CI/CD 流水线的最小闭环：构建、测试、扫描和可回滚发布》，讲分支合并后如何用自动检查守住交付质量。
💬 你在实际项目里遇到过分支长期不合并、冲突集中爆发或提交难回滚的问题吗？评论区聊聊。
（觉得有用点个赞+收藏，方便回头查阅）
🔧 相关可运行源码/资料已整理成资源包，可在我主页的资源里自取。
