日常开发如何管理好 Git 分支？

导读：本文基于日常开发的版本管理做简单梳理，来分析软件版本的定义相关问题，总结本篇文章希望对从事相关工作的同学能够有所帮助或者启发。

背景

打前段时间因为发现SpringBoot 官网修复缺陷问题进行了版本的溯源。简单梳理了下SpringBoot 官方版本的管理方式已经代码合并方式。

• JobExecutionExitCodeGenerator 线程安全问题

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

拓展版本

基于SpringBoot 的官方版本，我们公司在产品升级上也会做相应的版本管理。

▐ 分支管理

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

▐ feature 分支-功能迭代

日常开发中功能开发大多数都是当前迭代周期内完成，当然也有跨迭代周期完成的业务功能；此时我们针对日常迭代开发需求会各自拉取独立分支feature-需求单号，需求单号来源各个公司管理方式各不相同，有些通过禅道、天龙、定制表格记录等。唯一要求就是能够根据对应单号溯源的管理方式。

例如：

• 需求单号为13306的需求

我们开发则需要基于develop 分支拉取feature-13306迭代开发分支。当然为了标记个人我们也会调整标识，如：feature-lisz(姓名缩写)-13306

• 紧急缺陷单号为1008611的线上缺陷

这种情况是基础版本上线之后，出现在R版或者N版内，否则直接基于迭代开发分支进行修复合并至smoke和develop分支即可。至于紧急缺陷处理，下面在发布正式版本后再统一描述。

▐ feature 分支-功能迭代

在主功能完善后统一调整版本序号和发版标识。也就是我们常说的打标签tag

对于文档版本分支我们会定义两种版本

• N 版 ：一周或者两周迭代产生的版本(包含修复缺陷)
• R 版 ： 完整迭代功能闭环(包含大部分已修复)

上线版本我们一般采用R 版本应对，对于N版我们会对接各部分的迭代计划以及压测环境

在发布R/N 版本前我们会安排统一时间来修复遗留问题，一般三到四天时间统一修复当前版本的问题。当然也有一些可转为需求的缺陷单，可以将缺陷转为需求单，下个周期完成闭环。

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

在上诉feature迭代分支中，如果发现正式环境出现了紧急缺陷，改如何管理代码分支并且合理修复以及遴选分支合并呢？

当然我们绝对不能直接基于feature正在迭代开发的分支中进行修复并合并代码上去。这样很容易携带新的功能点(未经测试验收)合并至预发布或者稳定版本分支中。

不论是R版本还是N版本，如果在上一个周期闭环后出现的新问题。此时我们需独立拉取紧急修复缺陷分支 fix-lisz(姓名缩写)-14078(缺陷单号)，如下图所示：

总结

软件版本的定义，由于部门的匹配各公司都有各公司的管理方式和手段。上诉中提到的很多Git操作大多数基于迭代功能合并与缺陷修复该从如何拉取修复分支进行管理；但是多数情况下，功能迭代周期压缩会导致功能会延迟上线，这时候会导致我们研发手中的迭代功能分支会挤压。上线过程不可能直接覆盖式合并处理。此时我们应通过大量的遴选操作或者跨仓库遴选操作来完成一系列的代码合并问题。总结本篇文章希望对从事相关工作的同学能够有所帮助或者启发。