代码版本管理作为项目管理的一部分，也应当有一定的规范约束，目的是避免混乱，提高协作效率。由于Git已经成为主流的代码版本管理工具，虽然使用简单，但在团队使用中也应该对齐规范，否则在代码版本管理中反而会浪费一些毫无意义的成本开销，例如出现反复解决重复的代码冲突、与测试团队衔接不平滑、版本"超车"发布或者回滚困难等问题。
一、Git Flow概览
稳定分支
稳定分支通常使用主分支main，表示当前生产正在稳定运行的代码版本。
预发分支
预发分支通常使用staging，表示正在处于最后功能特性验证阶段的代码，验证完成后即上生产。由于修复分支的存在，因此预发分支在每一个迭代版本合并之前应当与主分支main完成一次merge，保证代码的同步。
迭代分支
使用敏捷开发的团队管理，迭代分支通常是一次sprint特性功能集合，用于管理该sprint的功能特性代码集合。每一次迭代开始时，迭代分支从稳定的主分支分流出来，通常以sprint-vx.y.z的形式来命名。每当开发分支开发以及自测后会通过MR/PR的形式合并到spint迭代分支中，并通过自动化机制发布到固定的验证环境，便于测试团队进行统一的功能验证。
开发分支
开发分支是从特定的迭代分支分流的代码分支，用于完成特定迭代分支中特定功能特性的分支。开发分支通常是以迭代分支-特性名称命名，但有的时候，开发分支通常是以开发者个人名义从迭代分支分流出来，以命名，但有的时候，开发分支会以开发者个人名义从迭代分支分流出来，以迭代分支-开发者姓名来命名，用于管理开发者在这次迭代的多个功能特性集合。一个开发分支管理多个特性的优点是在一个人负责当前迭代的多个功能时比较方便，但缺点是如果想要将开发分支中的多个功能特性拆分上线，可能较为困难。
修复分支
修复分支为了快速修复生产环境存在的紧急问题，通常会绕开预发分支而直接合并入主分支。由于修复分支可能会绕开测试团队，难以保障质量，我们应当尽可能减少修复分支的存在。一般的问题修复建议使用迭代分支流程来实现，例如，sprint-v1.1.1是对sprint-v1.1.0版本的一次修复，修复完成后合并入预发分支，在预发分支完成验证后再合并入主分支完成上线。
标签与里程碑
稳定分支在发布生产之前需要打上标签，如v1.1.0、v1.2.1。标签用于标识在稳定分支的某一个Commit是一个里程碑，用于更易人工理解的备注以及版本维护。这样在后续CICD流程中，对版本进行升级/回滚将会更友好。对于使用该服务的使用方来讲，也会更易于理解和响应。
标签的命名采用国际通用的GNU命名规则：
MajorVersion.MinorVersion.Revision即：主版本号.子版本号.修正版本号如：v0.0.1, v1.1.0, 1.7.1
MajorVersion主版本号：版本号通常是从0开始的，主版本号的变更表示一个全新的版本，例如：重大的重构、重大的feature改动、重大的不兼容性的变化。MinorVersion子版本号：发布较大的新feature功能，或者较大的重构或者模块变化，或者出现不兼容性改动，会增加子版本号。Revision修正版本号：往往是bug fix，或者增加较小的feature，较小的功能改进或者模块变化。- 当主版本号增加时，子版本号及修正版本号置
0。 - 当子版本号增加时，修正版本号置
0。
二、Git flow中的测试环节
通常测试团队的同学会在该分支上跑自动化测试、回归测试，并给出测试报告。
| Panel | ||
|---|---|---|
| ||
|