团队Git分支管理、迭代发布、分批投产标准化规范
# 团队Git分支管理、迭代发布、分批投产标准化架构规范（最终落地版）
# 一、文档概述
本文档为团队最终敲定的 Git 全流程落地规范，解决多人开发冲突混乱、版本溯源不清、分批投产困难、线上Bug回滚无序、测试环境不稳定等核心问题。
本规范为架构师级标准化流程，统一团队所有开发、合并、测试、发布、热修复、分批迭代行为，全员强制执行。
核心选型结论（团队最终确定方案）
放弃功能开关方案，采用 「需求优先级拆分 + 标准化Commit + Cherry-Pick 分批投产」 模式
固定四套分支体系：
main / test / dev / feature / hotfix线上版本完全依赖 Tag 溯源、回滚、发布，main 永远保持最新稳定上线代码
Bug 热修复全分支同步，杜绝迭代复现
从需求阶段分层，彻底解决多功能单分支、分批上线冲突问题
# 二、团队固定分支架构定义（唯一标准）
# 1. 分支角色定位
| 分支名 | 环境定位 | 读写规则 | 核心职责 |
|---|---|---|---|
| main | 生产环境（正式上线） | 只合不改、禁止直接提交 | 存放所有已上线稳定代码，唯一生产版本基线，依靠 Tag 标记发布版本 |
| test | 测试环境 | 迭代冻结、稳定回归 | 提供稳定测试基线，不被开发新代码频繁污染，专供测试全量回归 |
| dev | 开发集成分支 | 持续合并、持续集成 | 所有 feature 功能汇总集成，日常开发唯一合入分支 |
| feature/* | 个人功能分支 | 单人独立开发 | 承载所有新功能开发，按优先级拆分Commit，支持分批投产 |
| hotfix/* | 线上热修复分支 | 紧急修复、全分支同步 | 基于线上Tag修复生产Bug，修复后同步main/test/dev全分支 |
# 2. 核心架构原则
main 永远是当前最新上线稳定代码，仅通过 test 合并更新，不接受直接开发、不接受临时合并
所有历史版本、上线快照、回滚基线，唯一依靠 Git Tag 管理
测试环境独立 test 分支，彻底解决「开发未完成、测试环境被污染」问题
多人开发禁止直接在 dev 开发，必须走 feature 分支
# 三、版本号与Tag发布规范（生产唯一溯源）
# 1. 语义化版本规则（团队统一）
格式：v主版本.次版本.补丁版本
主版本：架构重构、不兼容破坏性更新
次版本：新增业务功能、迭代新版本（dev合入main）
补丁版本：线上Bug热修复（hotfix合入main）
# 2. 版本确定规则
每次上线前，读取 main 最新Tag，自动递增版本号
正式迭代功能 → 次版本+1
线上Bug修复 → 补丁版本+1
无Tag的Commit禁止上线，Tag为唯一生产发布快照
# 3. Tag使用规范
正式线上Tag禁止删除、禁止覆盖，问题版本直接新增补丁Tag
需要旧版本代码、回滚、复现Bug，只通过Tag切换
一个main分支可存在多个历史Tag，永久留存迭代基线
# 四、优先级拆分 + 分批投产标准流程（团队最终选定方案）
方案选型：放弃功能开关，采用「需求前置分级 + 标准化优先级Commit + Cherry-Pick分批上线」纯Git方案
# 1. 需求阶段：前置优先级拆分（源头治理）
所有需求进入开发前，必须在需求文档标注优先级：P0(紧急修复)、P1(高优投产)、P2(次优)、P3(低优)
拆分铁律：
无依赖、可独立运行的功能 → 单独优先级
强耦合、必须同时运行的功能 → 合并同一优先级
禁止跨优先级耦合，杜绝无法拆分投产的代码
# 2. 开发阶段：标准化优先级Commit规范
Commit 统一格式：类型+优先级: 功能描述
featP1: xxx高优新功能featP2: xxx次优新功能fixP0: xxx线上紧急修复fixP1: xxx迭代Bug修复
开发约束：单次提交只允许单一优先级代码，禁止P1/P2混合提交，保证后续可精准Cherry-Pick拆分投产。
# 3. 分批投产完整流程
所有功能在单一 feature 分支开发完成，按优先级分层提交
筛选当前需要投产的高优P1 Commit记录
dev 拉取最新基线，通过Cherry-Pick 精准摘取P1代码到dev
dev 合并至 test 分支，测试环境只回归当期投产功能
测试通过后 test 合并 main，打新版Tag上线
未投产P2/P3代码保留在原feature分支，下一轮迭代再摘取上线
# 五、线上Hotfix热修复全流程（含全分支同步）
# 1. 修复触发场景
main 线上版本出现Bug，需要紧急修复、快速补丁上线。
# 2. 标准步骤
基于线上稳定Tag新建 hotfix 分支
修复Bug、补充单测、自测验证
合并至 main 分支，打补丁版本Tag上线
强制同步全分支：hotfix 代码依次合并到 test、dev
# 3. 核心规则
不合并回 test：测试环境会残留旧Bug，无法回归验证
不合并回 dev：下一轮迭代上线会重复复现该Bug
线上修复永久只新增补丁Tag，不删除旧版本Tag
# 六、冲突治理终极方案（解决多人开发大量冲突）
# 1. 冲突根源根治
禁止全员直接在dev开发，统一feature分支开发
每日开发强制：个人feature分支每日同步一次dev，小冲突当日消化
上线前提前将 main 合并至 dev，在开发分支提前解决所有冲突，杜绝上线合并爆炸
# 2. 冲突处理铁律
谁开发、谁解决、谁负责校验
线上修复代码优先级最高，绝对不能被新功能代码覆盖
冲突解决后必须跑单测、自测，防止逻辑改错
# 七、单测补充规范（全阶段覆盖）
开发阶段：feature分支开发功能同步编写单测
提测阶段：dev->test前补齐缺失单测，不达标禁止合并
Bug修复阶段：hotfix修复必须补充回归单测，防止问题复现
# 八、整体迭代闭环（完整生命周期）
需求分级 -> feature优先级开发 + 标准化Commit -> 高优Commit Cherry-Pick至dev -> dev合并test测试冻结 -> test合并main -> 打Tag发布上线 -> 如有Bug走hotfix全分支同步 -> 下一轮迭代循环
# 九、四大场景标准流程速查
| 场景 | 标准流程 |
|---|---|
| 常规迭代 | dev 拉取 feature 开发 → 高优 P1 代码 cherry-pick 至 dev → dev 合并 test 回归 → test 合并 main 打 Tag 上线 |
| 分批投产 | 低优先级 P2/P3 代码保留在 feature 分支，不流入 dev/test/main |
| 线上故障 | main 对应 Tag 拉出 hotfix 修复 → 同步 main/test/dev 三分支 → 生成补丁 Tag |
| 冲突前置 | 上线前 main 代码提前合并至 dev，提前消化大量合并冲突 |
# 十、核心总结（团队不变准则）
main 永远是最新稳定上线代码，历史版本全部靠Tag溯源、回滚、复用
无功能开关，纯Git精准分批投产，靠「前置分级+优先级Commit+Cherry-Pick」落地
四分支隔离，彻底解决环境污染、冲突爆炸、版本混乱问题
线上修复三向同步（main/test/dev），杜绝迭代重复Bug
所有上线行为必有Tag，版本可追溯、可回滚、可复盘