1. 没有分支规范时,后端项目到底有多痛
先讲一个真实发生过的事。某个周五下午,团队准备发版本,测试环境和预发环境都验证得差不多了。结果临上线前,产品突然提了一个紧急改动,说某个页面的文案和数据展示要调整。一位同事图快,直接切到 develop 分支改了两行代码,提交之后顺手推了上去。
本来这事也不大,问题出在他改动前,develop 上已经有另一个新人在当天下午合入了一个半成品功能——那功能连编译都过不了,但因为没走到 CI,谁都没发现。结果等他把改动推到远程,测试环境直接 502,前端同事在群里连着发了三个问号。上线被迫推迟,所有人开始排查是哪一次的提交把环境搞挂了。
后来查清原因的时候,大家花了大半个小时去对比本地和远程分支的差异,才发现是那个半成品功能的锅。但更尴尬的是,那个同事当天下午本地还 pull 过两次,develop 分支在他本地和远程已经有分叉了,他根本不知道自己合进来的是什么东西。这就是典型的没有分支规范,或者有规范但不落地的后果。
后端项目的痛还不止于此。前端项目多数时候是一个页面、一个独立部署单元,后端不一样,多个服务、多个模块、多个人同时改同一个工程是常态。数据库迁移脚本有先后顺序,接口契约有兼容性要求,配置项有环境差异——任何一个人绕过正常流程直接往主分支提交代码,都有可能在某个瞬间把整个团队的交付状态打乱。
我见过不少团队,刚开始两三个人开发的时候,项目里只有一条 master 分支,谁想提交就提交,反正人少、冲突少了,改坏了喊一声就行。但随着人一多、需求一多、业务一复杂,这套玩法必然崩盘。分支规范不是流程绑架,它是让多人协作能并行推进而不互相踩脚的一套交通规则。这篇文章就把后端项目里最常用的一套 Git 分支开发规范和盘托出,直接从实际场景出发,说清楚怎么落地、怎么避坑。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 主流分支模型的选型对比:别一上来就照搬 Git Flow
Git 分支规范这件事,最容易踩的一个坑就是:看别人团队写了份很漂亮的分支模型文档,拿过来就用,结果发现流程太重,团队跑不起来。所以在聊具体规范之前,先花点时间把几种主流分支模型掰开揉碎讲一讲,搞清楚它们各自适合什么场景,再决定自己团队应该用哪一套。
2.1 Git Flow:功能全但偏重,适合版本化发布
Git Flow 是最经典的一套分支模型,由 Vincent Driessen 在 2010 年提出。它的核心思路是把分支分成五类:
- master/main:主分支,永远保持可发布状态,每一次提交对应一个线上版本
- develop:开发主干,所有功能分支的集散地,代表下一个版本的最新开发状态
- feature/*:功能分支,从 develop 拉出,开发完成后合并回 develop
- release/*:预发布分支,从 develop 拉出,用于某一个版本的收尾、Bug 修复,测试通过后合并回 master 和 develop
- hotfix/*:紧急修复分支,从 master 拉出,修复完成合并回 master 和 develop
这套模型的优点是边界清晰,每个分支职责明确,特别适合需要严格版本管理的场景——比如对外发布的 SDK、需要给不同客户出不同版本的软件、或者大型项目的季度版本管理。每个版本都有一个明确的 release 分支在维护,hotfix 也能独立于开发节奏快速上线。
但对于绝大多数做互联网产品的后端团队来说,Git Flow 偏重了。你想一下,如果团队每周甚至每天都要上线,release 分支的存在往往会引入额外的合并工作——功能合并到 develop,develop 再合并到 release,release 测试完还要合并回 master 和 develop,光是合并操作就够人烦的。更别说如果版本收敛时间长了,release 和 develop 之间的冲突会让人怀疑人生。
2.2 GitHub Flow / GitLab Flow:更轻量,贴近日常迭代
GitHub Flow 是最轻量的模型,核心就两条:master 永远保持可部署状态,所有功能从 master 拉分支,通过 Pull Request 合回 master。它的哲学是"每一次合入 master 的提交都应该可以直接上线"。
这套模型对于持续集成、持续部署做得好的团队来说非常舒服。功能分支短小、生命周期短,代码评审通过就合入主分支,然后自动部署到生产环境。没有版本的长期维护压力,没有 release 分支的概念,非常适合 Web 后端这种可以随时发布的服务。
GitLab Flow 在 GitHub Flow 的基础上加了环境分支的概念,比较常见的是增加 pre-production 和 production 两个分支,代码从 master 合并到 pre-production,验证通过再合到 production。这种方式适合那种有明确环境隔离需求、但发布节奏又不那么快的团队。
2.3 选型建议:把"持续发布"和"版本交付"分开考量
给后端团队的选型建议,我一般会先问三个问题:
- 发布频率是什么?每天发布一次以上,还是一个月发布一次?
- 是否有长期维护的多个线上版本?比如同时维护 V1.x 和 V2.x 两个大版本的需求
