Git分支管理实战：Spring Boot项目中的多环境协同与紧急修复流程

本文旨在梳理日常开发中的版本与分支管理实践，通过分析软件版本定义与代码合并策略，为相关领域的开发者提供一些可行的思路与启发。

前段时间，因为需要溯源 Spring Boot 官方修复的一个缺陷，我简单梳理了其版本管理方式及代码合并流程。

• JobExecutionExitCodeGenerator 线程安全问题

Spring Boot 官网：https://spring.io/projects/spring-boot#learn

基于 Spring Boot 官方的版本管理思路，我们公司在产品升级时也采用了类似的策略。

分支管理

一个清晰的分支模型是高效协作的基石。在我们的实践中，主要涉及以下几种分支类型：

• 主版本（Master）：用于存放稳定、可发布的代码。不同主版本间可能涉及重大架构调整，不一定兼容。
• 开发分支（Develop）：日常集成的主分支，所有新功能在合并到 Master 前，都先合并到此分支。
• 功能分支（Feature）：从 Develop 分支拉取，用于开发单个新功能或需求。
• 冒烟测试分支（Smoke）：从 Develop 分支拉取，用于进行快速的核心功能验证。
• 发布/热修复分支（Release/Hotfix）：从 Master 分支拉取，用于准生产环境测试和紧急缺陷修复。

在版本号定义上，我们遵循“主版本.次版本.增量版本”的格式：

• 主版本：可能进行大的架构调整，各大版本之间并不一定兼容。
• 次版本：在主版本架构不变的前提下，增加了一些新的特性或变化。
• 增量版本：用于 Bug 修复或细节完善。增量版本标识不一定是数字，例如 3.0.0-SNAPSHOT 中的 SNAPSHOT。

Feature 分支 - 功能迭代开发

日常的功能开发大多在当前迭代周期内完成。我们为每个需求或缺陷创建独立的功能分支，命名规则为 feature-需求单号，需求单号来源于公司内部的项目管理系统（如禅道、Jira 等），确保后续可溯源。

例如：

• 需求单号为 13306 的需求
  开发者需要基于 develop 分支拉取 feature-13306 分支进行开发。有时为了标识责任人，会加上姓名缩写，如 feature-lisz-13306。

• 紧急缺陷单号为 1008611 的线上缺陷
  如果该缺陷出现在已发布的版本（R版或N版）中，则需要特殊处理（下文详述）。若缺陷发现于开发阶段，则直接在当前迭代的 feature 分支上修复，并合并至 smoke 和 develop 分支。

版本发布与标签管理

当功能开发完成并通过测试后，会进入发布阶段。此时，我们会统一调整版本号并创建 Git 标签（Tag）。

我们定义了两种文档版本分支：

• N 版：通常为一到两周一个迭代周期产生的版本（包含新功能和缺陷修复）。
• R 版：一个完整功能迭代闭环后发布的稳定版本（包含该周期大部分已修复的问题）。

正式上线一般采用 R 版。N 版则用于对接内部迭代计划和压测环境。

在发布 R/N 版本前，通常会安排几天时间集中修复遗留问题。一些优先级较低或可转为需求的问题，可能会被安排到下个开发周期。

发布后如何管理 R/N 版本分支？

这是版本发布流程中的关键环节。假设在已发布的 R 版或 N 版中发现紧急缺陷，该如何处理？

绝对不能直接在正在开发的 feature 分支上修复并合并到稳定分支，这极易将未经测试的新功能代码带入生产环境。

正确的做法是：无论针对 R 版还是 N 版，都应从对应的稳定标签（Tag） 处拉取一个新的热修复（Hotfix）分支。例如，针对缺陷单号 14078，可以拉取分支 fix-lisz-14078。

修复并在此分支上测试通过后，再将代码分别合并（Cherry-pick）回 develop 分支以及对应的 R/N 版本维护分支，确保修复在所有相关分支上同步。

总结

软件版本与分支管理策略需与团队规模和项目节奏相匹配。上文主要阐述了日常功能迭代的合并与紧急缺陷修复的分支管理逻辑。

在实际软件开发流程中，常会遇到迭代周期压缩导致功能延迟上线、多个功能分支积压的情况。此时，不能简单地进行覆盖式合并，而需要借助大量的遴选（Cherry-pick）操作，甚至跨仓库的代码同步，来精准、安全地完成代码整合。希望本文的分享能对大家在实践中构建稳健的 Git分支管理 流程有所启发。也欢迎大家在技术论坛如 云栈社区 交流更多实战经验。