03-企业分支规范讲解Master/Develop/Feature/Bugfix/Release分支模型一、为什么要有分支规范上一篇我们搞懂了Git的底层原理——commit是一串哈希指针。那问题来了团队10个人每个人都往master上提交master就成了一条大杂烩线谁知道哪个commit是测试过的哪个是线上版本哪个是半成品分支规范的本质就是用分支隔离关注点开发归开发测试归测试发版归发版紧急修复归紧急修复。每条分支有明确的职责、明确的来源、明确的去向。目前业界最主流的分支模型有两种Git Flow经典模型分支多、流程重适合发版周期长、多端协作的项目GitHub Flow / Trunk-Based轻量模型只有master feature适合持续部署的Web项目我们的无人售货柜项目涉及后端微服务、安卓固件、小程序三端发版周期不同步、需要严格的版本管控Git Flow是更合适的选择。二、五大分支的职责与生命周期2.1 Master分支——生产环境的唯一来源命名master (或 main) 来源从 Release 分支合并 去向无它是终点 保护级别最高禁止直接pushMaster分支上每个commit都对应一个生产环境版本。无人售货柜线上跑的后端v1.2.0、安卓固件v1.2.0一定能在master上找到对应的Tag。关键规则永远不要在master上直接开发master的每次合并必须来自Release分支经过完整测试的代码每次合并到master后必须打Tag格式如v1.2.0-backend2.2 Develop分支——集成测试的主线命名develop 来源从 master 拉出长期存在 去向合并到 Release 分支 保护级别高只接受合并不直接pushDevelop是所有Feature分支的汇合点。开发者在Feature分支完成开发后合并到Develop进行集成测试。Develop上的代码应该是最新可用的开发版本但不保证稳定——因为多个Feature合并后可能有冲突。关键规则Feature分支完成后合并到DevelopDevelop定期与master同步把master的Bugfix合并回来不要直接在Develop上写代码通过Feature分支合并2.3 Feature分支——功能开发的工作区命名feature/开门接口字段统一改造 来源从 develop 拉出 去向合并回 develop 生命周期功能完成后删除每个功能点一个Feature分支命名要见名知意。比如后端要改造开门接口返回字段分支名叫feature/door-api-field-refactor而不是feature/zhangsan——三个月后没人记得张三做了什么。关键规则一个Feature尽量在一个迭代周期内完成Feature分支开发期间定期从Develop拉取最新代码git merge develop或git rebase develop避免积累冲突合并到Develop后删除远程和本地的Feature分支2.4 Bugfix分支——线上Bug紧急修复命名bugfix/货柜门状态不回传 来源从 master 拉出注意是master不是develop 去向合并回 master 和 develop 生命周期修复验证后删除线上出了Bug从master拉Bugfix分支修复后合并回master发版同时合并回Develop保证后续开发不会踩同一个坑。为什么从master拉而不是从develop因为develop上可能有未测试通过的新功能代码基于develop修复Bug会带入不可控的变更。master是稳定的线上版本从它拉分支修复最安全。关键规则Bugfix分支只修Bug不加功能修复后必须同时合并到master和develop双合并合并到master后打新版本Tag如v1.2.1-backend2.5 Release分支——发版前的冻结与预检命名release/v1.2.0 来源从 develop 拉出 去向合并到 master 和 develop 生命周期发版后删除当Develop上累积了足够的功能准备发版时从Develop拉出Release分支。Release分支进入冻结期——不再加新功能只做Bug修复、版本号更新、配置调整。Release分支的意义在于隔离发版准备和持续开发测试团队在Release分支上做回归测试开发团队可以继续在Develop上开发下个迭代的功能互不干扰。关键规则Release分支只允许Bugfix提交不允许新功能测试通过后合并到master打Tag发布同时合并回Develop把Release期间的Bugfix同步回去合并方式用--no-ff保留合并记录三、分支流转全景图master ●─────────────────●───────────────●────────── (Tag v1.2.0) \ ↑ /↑ \ │ / │ develop ●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●● \ ↑ ↑ ↑ ↑ ↑ \ │ │ │ │ │ feature ●●●●●●● ●●●●●●●●● │ │ │ │ │ │ │ │ release ●●●●●●●● │ │ │ │ │ bugfix ●●●●●●●●●● │ (合并到masterdevelop)四、无人售货柜项目分支实战示例以一次完整迭代为例迭代目标后端开门接口字段统一改造 安卓固件适配 小程序支付流程优化第1天从develop拉出三个Feature分支 feature/door-api-field-refactor (后端) feature/firmware-door-api-adapt (安卓固件) feature/miniapp-payment-optimize (小程序) 第1-7天各端在各自Feature分支开发 后端完成接口改造安卓固件适配新字段小程序优化支付流程 第7天三个Feature分支合并到develop develop上进行联调测试 第8天从develop拉出release/v1.2.0 测试团队在release分支做回归测试 发现安卓固件有个Bugdoor_status字段解析时类型转换错误 第8-9天在release/v1.2.0上修复Bug 同时把这个Bugfix合并回develop 第10天release/v1.2.0测试通过 合并到master打Tagv1.2.0-backend / v1.2.0-firmware / v1.2.0-miniapp 合并回develop 删除release/v1.2.0和三个feature分支 第11天线上发现小程序支付回调偶发失败 从master拉出bugfix/payment-callback-fix 修复后合并到master打Tag v1.2.1-miniapp 合并回develop五、合并策略merge vs rebase vs squash策略命令特点适用场景Merge (默认)git merge feature/xxx保留完整分支历史有merge commitFeature → DevelopRelease → MasterMerge --no-ffgit merge --no-ff feature/xxx强制生成merge commit明确标记分支合并点Release → MasterBugfix → MasterRebasegit rebase develop把Feature的commit嫁接到目标分支顶端历史线性Feature开发期间同步Develop最新代码Squash Mergegit merge --squash feature/xxx把Feature多个commit压缩成一个小功能分支避免commit历史太碎推荐策略Feature → Developgit merge --no-ff保留分支痕迹方便追溯哪个功能是谁做的Release → Mastergit merge --no-ff明确标记发版点Bugfix → Mastergit merge --no-ff标记修复点Feature开发期间同步Developgit rebase develop保持线性历史减少merge commit噪音六、分支保护规则配置在GitLab/Gitea中配置分支保护分支允许推送允许合并允许Force Pushmaster无Maintainer禁止develop无Developer禁止release/*无Maintainer禁止配合CI流水线只有CI通过的Merge Request才能合并到develop/master从机制上杜绝漏测代码进入主干。分支规范不是形式主义它是团队协作的交通规则——每个人都按规则走代码就不会撞车。下一篇我们把这个模型落地到无人售货柜三端项目中讲清楚后端微服务、安卓固件、小程序各自的分支怎么管、怎么对齐。
03-企业分支规范讲解Master/Develop/Feature/Bugfix/Release分支模型一、为什么要有分支规范上一篇我们搞懂了Git的底层原理——commit是一串哈希指针。那问题来了团队10个人每个人都往master上提交master就成了一条大杂烩线谁知道哪个commit是测试过的哪个是线上版本哪个是半成品分支规范的本质就是用分支隔离关注点开发归开发测试归测试发版归发版紧急修复归紧急修复。每条分支有明确的职责、明确的来源、明确的去向。目前业界最主流的分支模型有两种Git Flow经典模型分支多、流程重适合发版周期长、多端协作的项目GitHub Flow / Trunk-Based轻量模型只有master feature适合持续部署的Web项目我们的无人售货柜项目涉及后端微服务、安卓固件、小程序三端发版周期不同步、需要严格的版本管控Git Flow是更合适的选择。二、五大分支的职责与生命周期2.1 Master分支——生产环境的唯一来源命名master (或 main) 来源从 Release 分支合并 去向无它是终点 保护级别最高禁止直接pushMaster分支上每个commit都对应一个生产环境版本。无人售货柜线上跑的后端v1.2.0、安卓固件v1.2.0一定能在master上找到对应的Tag。关键规则永远不要在master上直接开发master的每次合并必须来自Release分支经过完整测试的代码每次合并到master后必须打Tag格式如v1.2.0-backend2.2 Develop分支——集成测试的主线命名develop 来源从 master 拉出长期存在 去向合并到 Release 分支 保护级别高只接受合并不直接pushDevelop是所有Feature分支的汇合点。开发者在Feature分支完成开发后合并到Develop进行集成测试。Develop上的代码应该是最新可用的开发版本但不保证稳定——因为多个Feature合并后可能有冲突。关键规则Feature分支完成后合并到DevelopDevelop定期与master同步把master的Bugfix合并回来不要直接在Develop上写代码通过Feature分支合并2.3 Feature分支——功能开发的工作区命名feature/开门接口字段统一改造 来源从 develop 拉出 去向合并回 develop 生命周期功能完成后删除每个功能点一个Feature分支命名要见名知意。比如后端要改造开门接口返回字段分支名叫feature/door-api-field-refactor而不是feature/zhangsan——三个月后没人记得张三做了什么。关键规则一个Feature尽量在一个迭代周期内完成Feature分支开发期间定期从Develop拉取最新代码git merge develop或git rebase develop避免积累冲突合并到Develop后删除远程和本地的Feature分支2.4 Bugfix分支——线上Bug紧急修复命名bugfix/货柜门状态不回传 来源从 master 拉出注意是master不是develop 去向合并回 master 和 develop 生命周期修复验证后删除线上出了Bug从master拉Bugfix分支修复后合并回master发版同时合并回Develop保证后续开发不会踩同一个坑。为什么从master拉而不是从develop因为develop上可能有未测试通过的新功能代码基于develop修复Bug会带入不可控的变更。master是稳定的线上版本从它拉分支修复最安全。关键规则Bugfix分支只修Bug不加功能修复后必须同时合并到master和develop双合并合并到master后打新版本Tag如v1.2.1-backend2.5 Release分支——发版前的冻结与预检命名release/v1.2.0 来源从 develop 拉出 去向合并到 master 和 develop 生命周期发版后删除当Develop上累积了足够的功能准备发版时从Develop拉出Release分支。Release分支进入冻结期——不再加新功能只做Bug修复、版本号更新、配置调整。Release分支的意义在于隔离发版准备和持续开发测试团队在Release分支上做回归测试开发团队可以继续在Develop上开发下个迭代的功能互不干扰。关键规则Release分支只允许Bugfix提交不允许新功能测试通过后合并到master打Tag发布同时合并回Develop把Release期间的Bugfix同步回去合并方式用--no-ff保留合并记录三、分支流转全景图master ●─────────────────●───────────────●────────── (Tag v1.2.0) \ ↑ /↑ \ │ / │ develop ●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●● \ ↑ ↑ ↑ ↑ ↑ \ │ │ │ │ │ feature ●●●●●●● ●●●●●●●●● │ │ │ │ │ │ │ │ release ●●●●●●●● │ │ │ │ │ bugfix ●●●●●●●●●● │ (合并到masterdevelop)四、无人售货柜项目分支实战示例以一次完整迭代为例迭代目标后端开门接口字段统一改造 安卓固件适配 小程序支付流程优化第1天从develop拉出三个Feature分支 feature/door-api-field-refactor (后端) feature/firmware-door-api-adapt (安卓固件) feature/miniapp-payment-optimize (小程序) 第1-7天各端在各自Feature分支开发 后端完成接口改造安卓固件适配新字段小程序优化支付流程 第7天三个Feature分支合并到develop develop上进行联调测试 第8天从develop拉出release/v1.2.0 测试团队在release分支做回归测试 发现安卓固件有个Bugdoor_status字段解析时类型转换错误 第8-9天在release/v1.2.0上修复Bug 同时把这个Bugfix合并回develop 第10天release/v1.2.0测试通过 合并到master打Tagv1.2.0-backend / v1.2.0-firmware / v1.2.0-miniapp 合并回develop 删除release/v1.2.0和三个feature分支 第11天线上发现小程序支付回调偶发失败 从master拉出bugfix/payment-callback-fix 修复后合并到master打Tag v1.2.1-miniapp 合并回develop五、合并策略merge vs rebase vs squash策略命令特点适用场景Merge (默认)git merge feature/xxx保留完整分支历史有merge commitFeature → DevelopRelease → MasterMerge --no-ffgit merge --no-ff feature/xxx强制生成merge commit明确标记分支合并点Release → MasterBugfix → MasterRebasegit rebase develop把Feature的commit嫁接到目标分支顶端历史线性Feature开发期间同步Develop最新代码Squash Mergegit merge --squash feature/xxx把Feature多个commit压缩成一个小功能分支避免commit历史太碎推荐策略Feature → Developgit merge --no-ff保留分支痕迹方便追溯哪个功能是谁做的Release → Mastergit merge --no-ff明确标记发版点Bugfix → Mastergit merge --no-ff标记修复点Feature开发期间同步Developgit rebase develop保持线性历史减少merge commit噪音六、分支保护规则配置在GitLab/Gitea中配置分支保护分支允许推送允许合并允许Force Pushmaster无Maintainer禁止develop无Developer禁止release/*无Maintainer禁止配合CI流水线只有CI通过的Merge Request才能合并到develop/master从机制上杜绝漏测代码进入主干。分支规范不是形式主义它是团队协作的交通规则——每个人都按规则走代码就不会撞车。下一篇我们把这个模型落地到无人售货柜三端项目中讲清楚后端微服务、安卓固件、小程序各自的分支怎么管、怎么对齐。
