核心目标：降低代码冲突、保障主干稳定性、适配持续集成、清晰追溯版本、支持并行开发 + 紧急热修复。没有万能方案，先区分团队规模、发布模式（迭代发布 / 持续交付）选型，再落地规范、自动化校验。
一、主流分支模型对比（选型依据）
表格
选型建议
传统项目、固定版本交付（政企、软件套装） → GitFlow（简化版，不建议原版复杂流程）
互联网 SaaS、每日 / 随时发布、DevOps 完善 → Trunk Based Development（优先推荐现代团队）
中小型团队、持续部署、流程轻量化 → GitHub Flow
❌ 避坑：不要直接照搬原版 GitFlow，绝大多数团队会过度复杂化，建议简化 GitFlow。
二、通用规范：分支命名规范（所有模型通用，强制标准化）
统一命名格式（推荐 kebab-case）
plaintext
<类型>/<工单ID>-<简短描述>
分支类型清单
feature/：新需求、新功能开发示例：
feature/TICK-123-user-login
bugfix/：开发阶段缺陷（未上线）示例：
bugfix/TICK-456-order-calc
hotfix/：线上紧急故障修复示例：
hotfix/TICK-789-pay-timeout
release/：版本准备分支（GitFlow 使用）示例：
release/v1.4.0
docs/：仅文档、注释修改refactor/：代码重构，无功能变更test/：测试验证临时分支（禁止长期保留）
硬性约束
所有功能分支生命周期尽量短（TBD 建议 1～3 天，避免长期分叉引发巨型冲突）
禁止多人共用一个 feature 分支，避免强制推送覆盖代码
临时分支完成合并后立即删除，仓库不要堆积大量废弃分支
三、两套落地最强实践方案（可直接照搬）
方案 A：Trunk Based Development（主干开发｜现代 DevOps 首选）
核心规则
唯一长期保护主干：
mainmain任何时刻必须可编译、可部署、通过自动化测试所有开发从
main切短分支：feature/*/bugfix/*工作流：
plaintext
main ← checkout → feature/xxx ↓开发、频繁从main同步代码（git rebase main） ↓完成 → MR/PR（代码评审） ↓自动化CI：单元测试、代码扫描、编译校验 ↓评审通过 → merge到main（推荐Squash合并） ↓删除feature分支线上紧急修复 hotfix：同样从 main 拉出，修复后合并回 main，走正常发布流程
版本管理：使用 Git Tag 标记正式版本
v1.2.3bash
git tag -a v1.2.3 -m "正式版本v1.2.3" git push origin v1.2.3
关键配套手段（TBD 能成功的必要条件）
Squash 合并：一个需求最终在 main 只保留一条提交记录，主干历史干净
特性开关 Feature Flag：未完成功能不阻塞合并，代码先合入主干，通过开关控制是否启用，避免长期分支
CI 持续巡检 main 分支：一旦主干破坏，告警所有开发者
禁止直接 push 代码到 main，必须经过 PR/MR 评审
方案 B：简化版 GitFlow（适合周期发布、多版本维护项目）
原版 GitFlow 过于繁琐，进行工业界通用简化：
长期永久分支（受保护，禁止直接 push）
main：对应生产环境，永远存放已经上线稳定代码，只能由 release/hotfix 合并进来develop：开发集成分支，所有新功能合并到此，作为下个版本开发基线
短期临时分支
feature/*、bugfix/*、release/vX.Y.Z、hotfix/*
完整工作流
新功能开发
develop→ feature 分支 → 开发完成 → PR 合并回develop→ 删除 feature版本发布准备
从
develop拉出release/v1.5.0只允许 bug 修复，禁止新增功能；测试完成后：
合并至
main，打上版本 tagv1.5.0同步合并回
develop（把 release 期间修复的 bug 带回开发分支）删除 release 分支
线上紧急热修复 hotfix
从
main拉出 hotfix 分支；修复测试完成合并至
main，更新版本 tag必须同步合并回 develop（防止下一个版本丢失线上修复）
删除 hotfix 分支
⚠️ 经典坑：hotfix 只合并 main，忘记合并 develop，导致新版本 bug 复现！
四、合并策略选择（极其影响历史整洁度）
仓库开启保护规则，统一合并方式：
Squash and merge（推荐绝大多数场景）
将分支所有提交压缩为一条 commit并入主干。主干历史线性干净，方便回滚。适合 feature 分支。
Merge commit（保留所有提交）
保留完整分叉历史，适合大型 release 分支，需要查看所有迭代过程
Rebase merge
线性历史，但多人协作时冲突风险高；不建议普通开发者随意使用
❌ 禁止：直接 git push --force 推送受保护主干；禁止强制覆盖共享分支
五、必须配套的仓库保护策略（光有规范没用，需要强制）
1. 分支保护规则（GitLab/GitHub/Gitee 均支持）
main/develop禁止直接 push；只允许 PR/MR 合并合并前置条件：
✅ 至少 1 人代码评审通过
✅ CI 流水线全部通过（单元测试、静态代码扫描、构建成功）
✅ 禁止冲突未解决直接合并
2. Commit 信息规范（推荐 Conventional Commits）
plaintext
<类型>[可选范围]: 描述
[正文详细说明]
关联工单：#123
类型：feat/fix/refactor/docs/test/chore
示例：
feat(login): 增加短信验证码登录
好处：自动生成更新日志（CHANGELOG），语义清晰。
3. 自动化工具增强落地
pre-commit：本地代码格式化、lint 检查
CI：自动运行测试、漏洞扫描、分支命名校验
自动删除合并完成的分支，清理仓库
定期清理长期未更新的僵尸分支
六、高频问题与避坑清单
长期 feature 分支，和主干差距越来越大，合并爆炸冲突？
✅ 对策：开发期间定期 rebase 主干；优先使用特性开关，缩短分支生命周期，不要拉出分支开发几周。
hotfix 修复后新版本再次出现同一个 bug？
✅ 对策：hotfix 合并 main 后，强制同步合并回 develop 分支。
多人并行开发，频繁代码冲突？
✅ 统一代码格式化规则；模块解耦；减少大文件并行修改；小粒度拆分需求。
需要同时维护多个历史版本（v1、v2 两条产线）？
在 GitFlow 基础上增加版本维护分支
support/v1.x；hotfix 需要向多个维护分支同步。什么时候使用 rebase，什么时候使用 merge？
私有个人分支：使用
git rebase main保持分支跟进主干公共共享分支（develop/main）：禁止 rebase，只用 merge，避免破坏他人本地代码
七、落地实施步骤（团队推行路线）
根据发布模式选定分支模型（TBD 优先尝试）
输出文档：分支命名、PR 规范、合并策略、commit 规范
在代码平台配置分支保护、CI 校验规则（用工具强制，不靠自觉）
组织团队培训，整理标准操作命令模板
试运行 1～2 个迭代，收集痛点微调规则，避免过度复杂
定期复盘：分支生命周期、冲突频率、发布阻塞点，持续优化
八、常用标准命令模板（可直接下发团队）
# 1. 创建功能分支
git checkout main
git pull
git checkout -b feature/TICK-123-user-login
# 2. 同步主干最新代码（个人分支定期执行）
git fetch origin
git rebase origin/main
# 3. 推送分支发起PR
git push -u origin feature/TICK-123-user-login