六条分支，一条主干：我的 Git 分支管理心得本文分享一套适配中小团队的 Git 分支方案：六条分支 + 一条主干，明确

规范清晰・减少冲突・协作高效

几年前我接手过一个六人小团队，代码写得不算差，但协作方式很 "野生"：所有人挤在一个分支上开发，上线前一周全员解冲突，一解就是一个通宵。

更糟的是有一次线上出 bug，值班同学直接在 main 上改了几行，验证没问题就发了版 —— 两周后新版本上线，同一个 bug 原地复活。排查了半天才发现，那个修复从来没人合回开发分支。

那次复盘之后，我把团队的 Git 协作整个重写了一遍。这套流程跟着我换了两个团队，稳定跑了两三年，今天把完整做法整理出来，供你参考和裁剪。

一、先说说我为什么不再相信 "口头约定"

早期团队不是没有规范，规范写在离职同事的笔记里，实际执行全靠 "问一下老王"。最后滋生出四大问题：

表格

症状	我见过的现场	根因
冲突集中爆发	上线前一周，全组通宵解冲突	所有人共用一个分支开发
环境错配	产品拿着 DEV 页面追问上线时间	分支与部署环境没有一一对应
历史不可读	`git log` 满屏都是 `update`、`修改`、`fix bug`	提交信息没有统一约定
救火无序	hotfix 只改 main，下个版本 bug 再次复现	线上修复没有回合到开发主干

这四块环环相扣：分支模型解决代码在哪改，环境映射解决版本对应关系，Commit 规范解决问题追溯，最后靠流程纪律兜底。 缺任何一块，前面所有规范带来的收益都会被抵消。

二、我们最终沉淀下来的六条分支

一开始试过极简版（main + feature），七八个人协作直接崩盘；也试过完整版 git-flow，小团队觉得流程太重。

最终落地折中方案：六条分支，各司其职，生命周期严格区分。

表格

分支	定位	来源分支	合并去向	生命周期
`main`	生产主分支，永远等同于线上版本	`release`、`hotfix`	只进不出，禁止向外合并	长期常驻
`develop`	开发主干，始终保持可运行状态	`feature`、`hotfix`	合并到 `test`	长期常驻
`feature/*`	单需求 / 单模块开发分支	`develop`	合并回 `develop`	需求上线立刻删除
`test`	提测分支，用于测试验证	`develop`	合并到 `release`	版本迭代阶段存在
`release/*`	预发布 UAT 验收分支，只修 bug 不加新功能	`test` / `hotfix`	先合入 `main`，再回合到 `develop`	单个版本周期
`hotfix/*`	线上紧急故障修复分支	`main`	同时合并到 `main` + `develop`	按需临时创建

给新人记忆口诀：

main 是已经上线的事实，develop 是即将发布的计划，feature 是还在开发的想法。

三者一旦混用，绝大多数发布事故都会接踵而至。

小提示：feature 分支统一用模块命名，例如 feature/user_module；杜绝 feature/dev1、feature/aaa 这类无意义名称，避免后期无人知晓分支用途。

三、流转路径只有五条，背下来就能用

分支模型的核心不在于分支名称，而在于流转路径固定不变。新人入职只需要吃透下面 5 条流程，绝大多数协作问题都能迎刃而解。

路径 1：日常需求开发（develop → feature → develop）

# 从开发主干拉出功能分支
git checkout develop
git pull
git checkout -b feature/xxx_module

# 开发完成后合并回develop，必须加--no-ff保留分支记录
git checkout develop
git merge --no-ff feature/xxx_module

路径 2：版本提测（develop → test）

功能自测完成、MR 评审通过之后，把代码合并到 test 分支交付测试人员。

git checkout test
git merge --no-ff develop

路径 3：版本发布（test → release → main → develop）

# 从test拉出预发布分支
git checkout test
git checkout -b release/v1.4.0

# 验收完成，合并到生产main
git checkout main
git merge --no-ff release/v1.4.0

# 关键：把所有bug修复回合到开发主干
git checkout develop
git merge --no-ff release/v1.4.0

路径 4：线上紧急修复（main → hotfix → main + develop）

# 基于线上main拉出修复分支
git checkout main
git checkout -b hotfix/fix_online_bug

# 修复完成，先合并到生产环境
git checkout main
git merge --no-ff hotfix/fix_online_bug

# 重中之重：必须同步合并到develop，否则下个版本bug会再次复活
git checkout develop
git merge --no-ff hotfix/fix_online_bug

开头那次线上事故，就是这条流程只走完了一半。 只合并 main、不回合 develop，等于主动给下一版本埋下隐患。

路径 5：线上版本回滚（不新增任何分支）

线上出现严重问题，优先使用 git revert 生成反向提交，保证提交历史完整可追溯，谁做的回滚一目了然。

严格禁止对已经推送到远端的 main 执行 reset --hard 强推：改写公共基线，省下十几分钟排查时间，最后要花一整晚修复所有人的代码基线。

四、一条分支，只对应一个环境

分支模型是骨架，分支与环境一一对应就是血管。我们踩过最大的坑并不是 Git 操作问题，而是版本与环境对不上：产品拿着 DEV 环境半成品提变更，测试在混杂未完成功能的环境验收，所有人都分不清线上到底是哪一版代码。

后来我们把对应关系固化，任何人不得随意打破：

表格

分支	部署环境	是否对外开放访问	约束规则
`main`	PRO 生产环境	开放访问	所有提交必须经过代码评审 + CI 校验，禁止直推
`develop`	DEV 开发环境	开放访问	开发自测专用，允许存在不稳定代码
`feature/*`	无对应环境	禁止访问	功能未完成不提供入口，防止半成品被当成正式版本验收
`release/*`	FAT 验收环境	开放访问	产品、测试在此完成签字验收
`hotfix/*`	临时 UAT 环境	仅内部临时验证	修复验证通过后才允许合并进生产 main

补充缩写说明，避免新人混淆：

PRO：生产环境
DEV：开发环境
FAT：功能验收测试环境
UAT：用户验收测试环境

新人高频疑问：为什么 feature 分支不能单独部署测试环境？一旦对外开放访问，一定会有人把半成品当成正式版本，测试结论直接失效。 限制不可访问不是刻意刁难，而是从源头杜绝版本误用。

环境错配带来的问题排查起来非常玄学 —— 代码版本和页面现象失去一一对应的关系，大量时间浪费在核对版本上。

五、Commit 规范：把提交日志变成可检索资产

早期只靠一句 "写清楚提交内容" 软性约束，日志里依旧全是 update、修改代码。

后来统一强制 7 种提交类型，彻底根治日志混乱问题。

统一格式：<type>(<scope>): <subject>

scope：填写对应模块名
subject：祈使句，结尾不加句号，控制在 50 字以内

表格

类型	含义	标准示例
`feat`	新增业务功能	`feat(order): 支持订单按时间区间筛选`
`fix`	修复线上 / 测试 bug	`fix(cart): 修复数量为0时仍可下单`
`docs`	仅修改文档内容	`docs(readme): 补充本地启动步骤`
`style`	代码格式调整，不改变业务逻辑	`style: 统一缩进为2空格`
`refactor`	代码重构，无新增功能、无 bug 修复	`refactor(user): 抽出手机号校验工具类`
`perf`	性能优化	`perf(list): 列表接口加索引，耗时降低60%`
`test`	新增 / 修改单元测试用例	`test(pay): 补充退款失败场景用例`

正反案例对比

表格

反面提交	标准正例
`update`	`feat(user): 新增手机号一键登录`
`修改bug`	`fix(order): 修复优惠券叠加后金额为负`
`提交一下`	`refactor(api): 统一接口错误码返回结构`

坚持这套规范带来的收益远超日志整洁：

可以自动生成版本变更日志（changelog）；
代码评审时可按提交类型区分审查重点：fix 重点看边界条件，refactor 重点保证行为不变；
语义化版本号可以自动升级：feat 升 minor 版本，fix 只升 patch 补丁版本。

新手极易混淆 refactor 和 style：仅调整缩进、空格、换行属于 style；调整代码结构但业务行为完全不变，才是 refactor。两类提交严禁夹带业务逻辑改动。把功能修改藏在 style 提交里，非常容易绕过代码审查，风险极高。

六、我定下的八条铁律（全部配套工具拦截）

写在 Wiki 里的制度很难落地，必须把规则固化成流程 + 工具校验，下面 8 条我们全部开启强制拦截：

main 与 release 开启分支保护，任何人禁止直接推送代码，包括管理员
所有代码合入 main 必须走 MR，至少 1 人评审 + CI 流水线全部通过
feature 分支存活时长不超过 3 天，大需求必须拆分成多个小迭代
所有合并操作统一加上 --no-ff 参数，保留完整分支拓扑，保证 git log --graph 可清晰追溯
每一次正式上线都必须打带注释的 tag（格式：v1.4.0），版本回滚有明确锚点
hotfix 修复必须执行双合并：同时合入 main + develop，缺一不可
每次提交前先执行 pull --rebase，减少大量无意义的 merge 提交
release 预发布分支只允许提交 bug 修复，任何新增功能一律退回 develop 排队下一版本

七、这些年我交过的学费

每一条规则背后都对应一次线上事故，挑几个印象最深的：

hotfix 只合并 main，忘记回合 develop 就是开篇那次事故。后续直接把双合并写入流程模板，MR 不勾选 develop 合并选项就无法提交。
feature 分支长期搁置，跨度长达一个月 单个需求开发三周才提 MR，500 多个文件产生大量冲突，两个人通宵逐条手动合并。现在超过 3 天未合入的分支，我会主动跟进拆分需求。
release 分支临时追加新功能 版本已经完成 UAT 验收，开发随手加了一个小按钮，导致整包需要重新全量回归测试。现在 release 分支出现非 fix 类型提交，CI 直接标红阻断合并。
全程使用 fast-forward 合并 提交历史看起来是一条直线，但是看不到每个功能对应的起止分支，线上出问题想按功能回滚，完全无从下手。
不拉取最新代码就直接 push 现在已经变成团队肌肉记忆：每天开工第一件事，先拉取远端最新代码，避免大面积冲突。

额外补充一大高频坑：分支与部署环境错配。拿 release 分支代码部署 DEV 环境，或者反过来，排查问题时会陷入无限内耗，反复核对 "我们看的是不是同一版代码"。

八、如果只能先做一件事

规范是有显性成本的：多写一段提交信息、多发起一次 MR、多等待一轮 CI 校验。但隐性收益巨大：不用通宵解冲突、不用靠回忆还原事故现场、不用反复追溯代码变更。

千万不要一上来直接落地完整六分支模型，推广阻力太大，很容易半途而废。

落地两步走，循序渐进：

先开启 main 分支保护，禁止任何人直推；
强制所有提交必须带上 feat/fix/docs 这类前缀。

两项改动最小，几乎不改变原有开发流程，两周就能让杂乱的 git 日志变得条理清晰。团队尝到追溯问题变简单的甜头之后，再逐步推行剩余分支管理纪律。

最后一句话总结：规范的 Git 协作流程，从来不是约束开发，而是把团队精力从代码管理，还给业务开发本身。