微服务项目不宜采用标准GitFlow，而应采用TBDD+Feature Branches轻量模型：main为唯一可部署分支，取消develop和release分支，用功能开关控制特性可见性，hotfix仅合入main，版本通过Git Tag管理，多环境靠配置而非分支隔离。
微服务项目里，Git分支模型不能照搬 GitFlow 原教旨——它太重，合并链路长，CI/CD 流水线容易卡在 release/* 分支上，反而拖慢交付节奏。真实场景下，团队普遍把 GitFlow “削薄”：砍掉 release/* 的长期存在，弱化 develop 的集成权威性，让 main 成为唯一可部署分支。
为什么微服务不适合标准 GitFlow
标准 GitFlow 要求 develop 分支持续集成所有功能，再切 release/x.y.z 分支做版本冻结、测试、打补丁。但在微服务中：
- 每个服务独立演进，
develop分支无法代表“整体可测状态”——Service A 的功能已就绪，Service B 还在联调，强行合入会污染集成环境 -
release/*分支生命周期长（数天到数周），期间其他服务的 hotfix 或紧急 feature 无法及时上线，违背微服务“独立发布”原则 - CI 流水线通常按服务粒度触发，不是按分支名统一构建；
release/*分支会导致构建配置重复、镜像标签混乱、K8s 部署清单难以对齐 - GitFlow 的
hotfix从main派生 → 合回main和develop，但微服务中 hotfix 往往只影响单个服务，合回develop可能引入未验证变更
微服务常用分支模型：TBDD + Feature Branches
更贴合实际的是“基于主干的开发（Trunk-Based Development, TBD）+ 功能分支”的轻量组合，核心是：main 永远可部署，所有变更必须快速合入 main。具体做法包括：
- 取消
develop分支，所有新功能从main拉出feature/*分支（如feature/order-timeout），开发完直接 PR 到main - 用功能开关（Feature Flag）控制长周期功能的可见性，避免分支长期存活；分支生命周期建议 ≤ 3 天
- 紧急修复走
hotfix/*分支，但从main拉出后，只合回main（不强制合回其他分支），合入后立即触发该服务的 CI/CD 流水线 - 版本管理靠 Git Tag（如
v2.1.0-service-auth），而非分支；每个服务有自己的 tag 命名空间，不共享release/*分支 - 多环境部署靠 K8s ConfigMap / Helm values 区分，不是靠分支隔离；
main提交同时触发 dev / uat / prod 多环境流水线（通过条件判断是否部署）
feature/* 分支命名与清理陷阱
微服务下 feature/* 分支若命名随意或清理滞后，会迅速污染远程仓库：
- 命名必须带服务标识，例如
feature/auth/jwt-refresh或feature/payment/rate-limiting，避免出现feature/login这类跨服务歧义名 - 禁止在
feature/*分支上合入其他人的提交——微服务强调“谁开发、谁负责测试、谁触发部署”，合入即失责边界 - PR 合并后，GitHub/GitLab 默认不自动删源分支；需在仓库设置中开启
Delete head branches after merge，否则两周后远程能看到上百个残留分支 - 本地
git fetch --prune频率要提高（建议每天一次），否则git branch -a显示大量已删除但本地未同步的远程分支，干扰开发
main 分支保护的关键配置项
当 main 成为唯一可部署分支，保护机制必须刚性落地：
- 启用
Require pull request reviews before merging，且至少 1 名 reviewer 来自该服务 Owner Group（不能只由 QA 或 Infra 团队审批） - 启用
Require status checks to pass before merging，关键检查项必须包含：ci/test-unit-service-x、ci/build-docker-image、ci/security-scan；缺失任一，PR 不可合并 - 禁用
Allow force pushes和Allow deletions——main是神圣不可逆的，历史提交必须完整可追溯 - 配置
Require linear history，拒绝git merge --no-ff，确保提交图谱扁平、每个 commit 都可单独回滚
真正难的不是选哪种模型，而是让所有人遵守同一条规则：main 就是生产，任何绕过它的操作（比如本地改完直接 push、用临时分支跳过 CI）都会在某个凌晨三点把你叫醒。分支模型只是骨架，持续校准权限、清理习惯、强化自动化，才是它不散架的原因。
