在一段时间的工作过程中配置管理工作确实对我们的生产活动产生了巨大的工作量，现在就这个工作来进行梳理一下。
本文主要分为两部分：
1、借用软件系统分析师的配置管理部分内容来介绍配置管理的工作（原谅时间精力有限，原文基本已经涉及了在工作中涉及的大部分内容，无法再进行梳理加工，只是缺少案例和图描述完整的一个项目，要完整描述的话，需要花费的时间精力可能得好几天）；
2、介绍在生产活动中我们研发人员涉及的最多的开发库和受控库部分的git版本规范。
配置是在技术文档中明确说明并最终组成软件产品的功能或物理属性，包括即将受
控的所有产品特性，其内容及相关文档、软件版本、变更文档、软件运行的支持数据，
以及其他一切保证软件一致性的组成要素。软件配置管理(Software Configuration
Management,SCM)是指通过执行版本控制、变更控制的规程，以及使用合适的配置管
理工具，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效
保护。
一、配置管理概述
根据国家标准《软件工程术语》(GB/T11457---2006),配置管理是标识和确定系统中配置项的过程，在系统整个生存期内控制这些配置项的投放和更动，记录并报告配置的状态和变动要求，验证配置项的完整性和正确性。并对下列工作进行技术和行动指导与监督的一套规范：
(1)对配置项的功能特性和物理特性进行标识和文件编制工作。
(2)控制这些特性的变动情况。
(3)记录并报告这些变动进行的处理和实现的状态。
配置管理的目的在于运用配置标识、配置控制、配置状态和配置审计，建立和维护工作产品的完整性。CMMI把配置管理分为九大部分，分别是制订配置管理计划、识别配置项、建立配置管理系统、创建或发行基线、跟踪变更、控制变更、建立配置管理记录、执行配置审核、版本控制。而国家标准《信息技术 软件生存周期过程》(GB/T 8566第20章 项目管理)所规定的软件配置管理过程的活动有过程实施(编制配置管理计划)、配置标识、配置控制、配置状态报告、配置评价、发行管理和交付。
（一）配置管理过程
(1)编制软件配置管理计划。在项目启动时，项目经理首先要制订整个项目的开发
计划，它是整个软件开发工作的基础。配置管理计划是项目开发计划的一部分。
(2)配置标识。确定哪些内容应该进入配置管理，形成配置项，并确定配置项如何
命名，用哪些信息来描述配置项。配置标识是配置管理的基础性工作，是进行配置管理
的前提。
(3)变更管理和配置控制。配置管理最重要的任务就是对(配置项的)变更加以控
制和管理，其目的是对于复杂而无形的软件，防止在多次变更下失控，出现混乱。
(4)配置状态说明。配置状态说明也称为配置状态报告，其任务是有效地记录、报
告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了
解，以加强配置管理工作。
(5)配置审核。配置审核的任务是验证配置项对配置标识的一致性。软件开发的实
践表明，尽管对配置项做了标识，实现了变更控制和版本控制，但如果不做检查或验证，
仍然会出现混乱。配置审核的实施是为了确保软件配置管理的有效性，体现配置管理的
最根本要求，不允许出现任何混乱现象。
(6)版本控制和发行管理。在配置管理中，版本包括配置项的版本和配置的版本，
这两种版本的标识应该各有特点，配置项的版本应该体现出其版本的继承关系，它主要
是在开发人员内部进行区分。另外，还需要对重要的版本做一些标识，例如，对纳入基
线的配置项版本就应该做一个标识。
（二）配置管理计划
根据 GB/T 8567---2006 的规定，配置管理计划应该包括以下几个部分的内容：
(1)引言。包括配置管理计划的标识、系统概述、文档概述、组织和职责、配置管
理活动所需的各种资源等。
(2)引用文件。列出配置管理计划中引用的所有文档的编号、标题、修订版本和日
期，还应标识不能通过正常的供货渠道获得的所有文档的来源。
(3)管理。描述在各阶段中负责 SCM的机构和任务，以及要进行的评审和检查工
作，指出各阶段的产品应存放在哪一类配置库中；指出各机构的职责和它们之间的关系，
描述相关的接口控制；规定实现 SCM计划的主要里程碑；指明SCM适用的标准和规范，
以及这些标准和规范要实现的程度。
(4)SCM活动。描述配置标识、配置控制、配置状态记录与报告、配置检查与评审
等4个方面的 SCM活动。
(5)工具、技术和方法。指明为支持特定项目的 SCM 所使用的软件工具、技术和
方法，以及它们的目的，并在开发人员所有权的范围内描述其用法。
(6)对供货单位的控制。规定对供货单位进行控制的规程，从而使从软件销售单位
购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的 SCM
需求。
(7)记录的收集、维护和保存。规定要保存的 SCM 文档，以及用于汇总、保护和
维护工程文档的方法和设施(其中包括要使用的后备设施),并说明要保存的期限。
(8)配置项和基线。根据企业的有关规范，对不同类型的配置项建立命名规则，列
出识别到的所有配置项和所属的配置基线，并明确配置项的标识、作者(或负责人)和
配置时间。描述配置项和基线变更、发布的流程，以及相应的批准权限。
(9)备份。说明配置库和配置管理库的备份方式、频率和责任人。
(10)日程表。列出SCM活动的日程表，并确保配置管理活动的日程表与项目开发
计划、质量管理计划保持一致。
(11)注解。包含有助于理解配置管理计划的一般信息，例如，背景信息、词汇表、
原理等。这一部分应包含为理解配置管理计划需要的术语和定义，所有缩略词和它们在
配置管理计划中的含义的字母序列表。
(12)附录。提供那些为便于维护配置管理计划而单独编排的信息(例如，图表、
分类数据等)。为便于处理，附录可以单独装订成册，按字母顺序编排。
（三） 配置标识
软件开发中的文档和软件在其开发、运行、维护的过程中会得到许多阶段性的成果，
在开发和运行过程中还需要用到多种工具软件或配置。所有这些信息项都需要得到妥善
的管理，决不能出现混乱，以便在提出某些特定的要求时，将它们进行约定的组合来满
足使用的目的。这些信息项是配置管理的对象，称为配置项。
每个配置项的主要属性有名称、标识符、状态、版本、作者、日期等。配置项是一
个独立存在的信息项，可以把它看成一个元素，单独的一个元素发挥不了什么作用，但
随着工作的进展，出于不同的要求，需要将这些元素进行不同的组合，这个组合称为配
置。配置是一个信息系统产品在生存期各个阶段的不同形式(记录特定信息的不同媒体)
和不同版本的程序、文档及相关数据的集合，或者说是配置项的集合，它具有完整的
意义。
1.确定配置项
软件项目中形成的技术性文档和管理性文档，除一些临时性的文档外一般都应该进
行配置管理。一般来讲，判定一个文档是否进行配置管理的标准应该是此文档是否有多
个人需要使用，这些文档往往在开发的过程中不断地修正和扩展，要保证每个使用者都
使用同一版本的文档，就必须将这些文档纳入配置管理，成为受控的配置项。
(1)识别配置项。可能成为配置项组成部分的主要工作产品有过程描述、需求、设
计、测试计划和规程、测试结果、代码/模块、工具、接口描述等。在软件工程方面，RogerS.Pressman 认为至少以下所列的文档应该成为配置项：系统规格说明书、项目计划、需
求规格说明书、用户手册、设计规格说明、源代码、测试规格说明、操作和安装手册、
可执行程序、数据库描述、联机用户手册、维护文档、软件工程标准和规程。
(2)配置项命名。确定了配置项后，还需要对配置项进行合理、科学的命名。配置
项的命名绝不能随意为之，必须满足唯一性和可追溯性。一个典型的实例是采用层次式
的命名规则来反映树状结构，树状结构上节点之间存在着层次的继承关系。
(3)配置项的描述。由于配置项除了名称外还有一些其他属性和与其他配置项的关
系，因此，它可以采用描述对象的方式来进行描述。每个配置项用一组特征信息(名字、
描述、一组资源、实现)唯一地标识。配置项间的关系有整体和部分的关系及层次关系，
也有关联关系。配置项间的关系可以用MIL(Module Interconnection Language,模块内
连接语言)表示，MIL 描述的是配置项间的相互依赖关系，可自动构造系统的任何版本。
2.基线
基线(baseline)是项目生存期各开发阶段末尾的特定点，也称为里程碑(milestone),
在这些特定点上，阶段工作已结束，并且已经形成了正式的(通过了正式的技术评审)
阶段产品。
建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的
开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利
于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成
果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。
如果把软件看做是系统的一个组成部分，以下3种基线是最受人们关注的，分别是
功能基线、分配基线和产品基线。
(1)功能基线：指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统
设计规格说明书中对待开发系统的规格说明；或是指经过项目业主和承建单位双方签字
同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级
同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基
线是最初批准的功能配置标志。
(2)指派基线(分配基线):指在软件需求分析阶段结束时，经过正式评审和批准
的 SRS。指派基线是最初批准的指派配置标志。
(3)产品基线：指在软件组装与系统测试阶段结束时，经过正式评审和批准的有关
所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
另外，交付给项目组所在企业的外部客户的基线一般称为发行基线，企业内部使用
的基线称为构造基线。释放(release)是指在软件生存周期的各个阶段结束时，由该阶
段向下阶段提交该阶段产品的过程。它也指将系统测试阶段结束时所获得的最终产品向
用户提交的过程。后面这个过程也称为交付(delivery)。
提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整766
系统分析师教程
体来看待会造成麻烦。因为一个变更很可能只涉及到基线的很小部分。例如，假定某个
大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不
方便。
3.建立配置管理系统
在配置管理中，要建立并维护配置管理系统和变更管理系统。建立配置管理系统的
主要步骤如下：
(1)建立适用于多控制等级配置管理的管理机制。软件生存周期中不同时间所需的
控制等级不同，不同的系统类型所需的控制等级也不同。
(2)存储和检索配置项。
(3)共享和转换配置项。
(4)存储和复原配置项的归档版本。
(5)存储、更新和检索配置管理记录。
(6)创建配置管理报告。
(7)保护配置管理系统的内容。配置管理系统的主要功能有文档的备份与恢复、文
档的建档、从配置管理的差错状态下复原。
(8)权限分配。配置管理员为每个项目成员分配对配置库的操作权限。配置管理员
的权限最高，一般项目成员可拥有添加、检入/检出(check in/check out)、下载的权限，
但是不能有删除的权限。
4.配置库
配置库也称为配置项库，是用来存放配置项的工具。配置库记录与配置相关的所有
信息，其中存放受控的配置项是很重要的内容，利用配置库中的信息可评价变更的后果，
这对变更控制有着重要的意义。配置库有三类：
(1)开发库。存放开发过程中需要保留的各种信息，供开发人员个人专用。开发库
中的信息可能有较为频繁的修改，只要使用者认为有必要，无需对其做任何限制。因为
这通常不会影响到项目的其他部分。开发库对应配置管理系统中的动态系统(开发者系
统、开发系统、工作空间)。
(2)受控库。在开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。
存入的信息包括计算机可读的和人工可读的文档资料。应该对受控库内的信息的读写和
修改加以控制。受控库也称为主库，对应配置管理系统中的主系统(受控系统)。
(3)产品库。在开发的产品完成系统测试之后，作为最终产品存入产品库内，等待
交付用户或现场安装。产品库内的信息也应加以控制。产品库也称为备份库，对应配置
管理系统中的静态系统。
（四）变更控制
变更是指在项目的实施过程中，由于项目环境或者其他的各种原因对项目的部分或
项目的全部功能、性能、体系结构、技术、指标、集成方法和项目进度等方面做出改变。
项目变更是正常的、不可避免的。在项目实施过程中，变更越早，损失越小；变更越迟，
难度越大，损失也越大。项目在失控的情况下，任何微小变化的积累，最终都会对项目
的质量、成本和进度产生较大影响，这是一个从量变到质变的过程。
变更产生的原因主要有以下几个方面：
(1)项目外部环境发生变化，例如，政府政策的变化等。
(2)项目总体设计、需求分析不够周密详细，有一定的错误或遗漏。
(3)新技术的出现，设计人员提出了新的设计方案或新的实现手段。
(4)建设单位由于机构重组等原因造成业务流程的变化。
1.变更控制系统
变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其
中包括必要的表格或其他书面文件、责任追踪，以及变更审批制度、人员和权限。变更
控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。在
审批变更时，要加强对变更风险和变更效果的评估，并选择对项目影响最小的变更方案，
尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控
制系统。变更控制系统应当与项目管理信息系统一起通盘考虑，形成整体。
2.变更控制委员会
变更控制委员会(Change Control Board,CCB)也称为配置控制委员会(Configuration
Control Board),其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的
实施。CCB 的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个
组织不必是常设机构，可以根据工作的需要组成，其中的人员可以全职的，也可以是兼
职的。
如果 CCB 不只是控制变更，而是承担更多的配置管理任务，那就应该包括基线的
审定、标识的审定，以及产品的审定等工作，并且可能实际的工作需分为项目层、系统
层和组织层来组建，使其完成不同层面的配置管理任务。
3.变更控制的流程
一般来说，变更控制应该遵循以下的基本流程：
(1)变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
(2)变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
(3)变更决策。由CCB决定是否实施变更。
(4)变更实施。由管理者指定的工作人员在受控状态下实施变更。
(5)变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价，确定变
更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
(6)沟通存档。将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归
档。如提出的变更在决策时被否决，其初始记录也应予以保存。
变更申请需要采用书面的形式提出，主要内容有如下3个方面：
(1)变更描述。包括变更理由、变更的影响、变更的优先级等，就是要描述做什么
变更，为什么要做，以及打算怎么做的问题。
(2)对变更的审批。对变更的必要性、可行性的审批意见，主要是由配置管理员和
CCB 对此项变更把关。
(3)变更实施的信息。
在变更请求批准后，实施变更需要一段时间，要设置一种管理手段来反映变更所处
的状态，这就是变更状态说明，它可供项目经理和 CCB 追踪变更的情况。状态说明的
信息可以通过变更请求和故障报告得到，变更状态可分为三种：活动(正在实施变更)、
完成状态(已完成变更)和未列入变更状态。
4.利用配置库实现变更控制
配置项可以有三种状态：工作状态、评审状态和受控状态。开发中的配置项尚未稳
定下来，对于其他配置项来说是处于工作状态下(自由状态、草稿状态),此时它并未受
到配置管理的控制，开发人员的变更并未受到限制。但当开发人员认为工作已告完成，
可供其他配置项使用时，它就开始于稳定。把它交出评审，就开始进入评审状态；若通
过评审，可作为基线进入配置库，开始冻结，此时，开发人员不允许对其任意修改，因
为它已处于受控状态。通过评审表明它确已达到质量要求；但若未能通过评审，则将其
回归到工作状态，重新进行调整。配置项的状态变化过程如图20-6所示。
处于受控状态下的配置项原则上不允许修改，但这不是绝对的，如果由于多种原因
需要变更，就需要提出变更请求。在变更请求得到批准的情况下，允许配置项从库中检
出，待变更完成，并经评审后，确认变更无误方可重新入库，使其恢复到受控状态。
（五）版本控制
在配置管理中，所有的配置项都应列入版本控制的范畴。对于软件产品的版本有两
个方面的意思，一是为满足不同用户的不同使用要求，如用于不同运行环境的系列产品。如适合Linux,Windows,Solaris用户的软件产品分别称为Linux版、Windows版和 Solaris
版。它们在功能和性能上是相当的，原则上没有差别，或者说，这些是并列的系列产品。
对于这类差别很小的不同版本，互相也称为变体(variant)。
另一种版本的含义是在软件产品投入使用后，经过一系列的变更(例如，纠错、增
加功能、提高性能的更改等),而形成的一系列的顺序演化的产品，这些产品也称为一个
版本，每个版本都可说出它是从哪个版本导出的演化过程。
必须注意到，修正后的新版本往往不能完全代替老版本，尽管新版本有某些优越的
特性。因为一些用户仍然使用着老版本，并且不容易立刻做到"以旧换新",否则，可能
会打扰老版本原有的工作环境。显然，多个版本被多个用户同时使用的情况是不可避免
的现实。这就要求多个版本共存，这也就是配置管理要解决的一个重要课题。
一般来说，版本控制的流程如下：
(1)创建配置项。
(2)修改处于工作状态的配置项。
(3)技术评审或领导审批。
(4)正式发布。
(5)变更，修改版本号。
版本管理要解决的第一个问题是版本标识，也就是为区分不同的版本，要给它们科
学的命名。通常有2种版本命名的方法，分别是号码版本标识和符号版本标识。其中号
码版本标识以数字表示，如用1.0,2.0,1.2,2.1.1等表示版本号；符号版本标识是将重
要的版本属性有选择地给出，例如，SQL Server 2008、Jbuilder 2005等将版本产生的时
间给出。为了从版本标识上看到更多信息，可能给出更多的属性，例如，面向的客户群、
开发语言、硬件平台、生成日期等。
在配置管理中，版本包括配置项的版本和配置的版本，这两种版本的标识应该各有
特点，配置项的版本应该体现出其版本的继承关系，它主要是在开发人员内部进行区分。
另外，还需要对重要的版本做一些标记，例如，对纳入基线的配置项版本应该做一个
标识。
（六） 配置审核
配置审核的任务是验证配置项对配置标识的一致性。软件开发的实践表明，尽管对
配置项做了标识，实践了变更控制和版本控制，但如果不做检查或验证仍然会出现混乱。
这种验证包括：
(1)对配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象。
(2)配置标识的准则是否得到了遵循。
(3)变更控制规程是否已遵循，变更记录是否可供使用。
(4)在规格说明、软件产品和变更请求之间是否保持了可追溯性。
配置审核工作主要集中在两个方面，一是功能配置审核，即验证配置项的实际功效
与软件需求是否一致；二是物理配置审核，即确定配置项符合预期的物理特性。这里所
说的物理特性是指定的媒体形式。
1.配置审核的时机和步骤
配置审核要选择适当的时机，由项目经理决定何时进行配置审核工作。一般来说，
应该选择以下几种情况实施配置审核：
(1)产品交付或是产品正式发行前。
(2)开发的阶段工作结束之后。
(3)在维护工作中，定期地进行。
实施配置审核的审核人员可以包括项目组人员及非项目组人员，例如，其他项目的
配置管理人员、企业的内部审核员等。配置审核的步骤如下：
(1)由项目经理决定何时进行配置审核工作。
(2)质量保证组或项目组的配置管理组指定该项目的配置审核人员。
(3)项目经理和配置审核员决定审核范围。
(4)配置审核员准备配置审核检查单。
(5)配置审核员审核文档和记录，审核活动可能涉及到项目范围、配置项的检入/
检出、评审记录、配置项的变更历史、测试记录、文件的命名、变更请求、版本的编
号等。
(6)配置审核员在审核中发现不符合现象，并作记录。
(7)由项目经理负责消除不符合现象。
(8)配置审核员验证所有发现的不符合现象，确保已得到解决。
2.配置审核与正式技术评审
配置审核的目的就是要证实整个项目生存期中各项产品在技术上和管理上的完整
性。同时，还要确保所有文档的内容变动不超出当初确定的软件需求范围。使得配置具
有良好的可跟踪性。这是项目变更控制人员掌握配置情况、进行审批的依据，除了进行
配置审核外，还可以进行正式技术评审。
正式的技术评审着重检查已完成修改的配置项的技术正确性，评审者评价配置项，
决定它与其他配置项的一致性，是否有遗漏或可能引起的副作用。正式技术评审应针对
所有的变更进行。有关正式技术评审的知识，请阅读11.7.1节。
配置审核作为正式技术评审的补充，评价在评审期间通常没有被考虑的配置项的特
性。在某些情形下，配置审核的问题是作为正式技术评审的一部分提出的。但是，当配
置管理成为一项正式活动时，配置审核就被分开，而由质量保证小组执行了。
（七） 配置状态报告
为了清楚、及时地记载配置的变化，不至于到后期造成贻误，需要对开发的过程作出系统的记录，以反映开发活动的历史情况，这就是配置状态记录。该项活动主要是完
成配置状态报告的编制工作。
在配置状态报告中，需要对每一项变更进行详细的记录，包括：发生了什么?为什
么会发生?谁做的?什么时候发生的?会有什么影响?整个配置状态报告的信息流如下图
正如上图所示，每次新分配一个配置项，或者更新一个已有配置项或配置项标识，
或者一项变更申请被变更控制负责人批准，并给出了一个工程变更顺序时，在配置状态
报告中就要增加一条变更记录条目；一旦进行了配置审核，其结果也应该写入报告中。
配置状态报告可以放在一个联机数据库中，以便开发人员或者维护人员可以对它进行查
询或修改。此外，在配置状态报告中，新记录的变更应当及时通知给管理人员和其他项
目干系人。
配置状态报告对于大型开发项目的成功起着至关重要的作用。它提高了所有开发人
员之间的通信能力，避免了可能出现的不一致和冲突。它通过支持创建和修改记录、管
理报告配置项的状态或需求变化并审核变化来实现，它提供用户需要的功能，跟踪任意
模式的软件项，提供完整的各种变化的历史版本和汇总信息。配置状态报告的内容一般
包括以下各项：
(1)各变更请求概要：变更请求号、日期、申请人、状态、估计工作量、实际工作
量、发行版本、变更结束日期。
(2)基线库状态。
(3)发行信息。772
系统分析师教程
(4)备份信息。
(5)配置管理工具状态。
(6)配置管理培训状态。
参考文档：软件配置管理（一） - 知乎 (zhihu.com)、国家标准全文公开 (samr.gov.cn)、软件分析师教程官方书籍、HMS源码-规范-软件配置管理规范.pdf (uml.com.cn)、浅谈研发项目中的配置管理（概述篇） - 知乎 (zhihu.com)、浅谈研发项目中的配置管理（过程篇） - 知乎 (zhihu.com)
二、git版本规范
（一）Git Flow
1、概述
Git Flow是一种非常流行的Git分支管理模型，是由Vincent Driessen于2010年提出的分支管理模型。自那时以来，它被广泛采用，并为管理发布和功能开发提供了结构化的方法。它提供了一套具体的分支命名规则和工作流程，有助于团队更好地组织和管理代码的开发与发布。该模型由Vincent Driessen在他的博客上提出，并得到了广泛采用。您可以在以下链接中找到Git Flow模型的详细说明：
Git Flow - A successful Git branching model (Original Blog Post)
在该博客文章中，Vincent Driessen介绍了Git Flow的基本原则、分支类型以及在不同阶段的工作流程。该模型涵盖了主要分支（master和develop）、支持分支（feature、release、hotfix和bugfix）等。它提供了一种规范化的方式来处理特性开发、版本发布和Bug修复等常见的开发场景。
此外，还有一些Git Flow的扩展工具和插件，使得使用Git Flow更加方便。一些流行的Git Flow工具包括Git Flow工具本身、Git Flow AVH Edition、Git Extensions等。这些工具提供了一些命令行工具或图形界面，以简化Git Flow工作流程的使用。
如果你使用Scrum工作，并希望在冲刺结束时做一个发布，那么你将需要使用Git Flow。此外，如果您依靠 QA 在代码投入生产之前对其进行手动测试，那么这可能是您可能想要使用 Git Flow 的另一个原因。
2、分支
Git Flow定义了几个长期存在的分支：
- master：主分支，用于存放生产环境的代码。
- develop：集成分支，用于进行持续开发和功能合并。
- feature：功能分支，用于开发新功能。
- release：发布分支，用于准备新版本的发布。
- hotfix：热修复分支，用于紧急Bug修复。
3、优缺点
优点：
- 结构化工作流：Git Flow提供清晰有序的工作流程，适用于需要显式版本控制和正式发布的项目。
- 代码隔离：每个功能在独立的分支上开发，确保工作的清晰分离。
- 版本管理：Git Flow支持版本控制，并支持维护多个版本在运行。
局限性：
- 复杂性：Git Flow引入了复杂性，由于多个长期存在的分支，这使得它对于较小的项目或采用持续交付实践的团队不太合适。
- 开销：管理和合并多个分支可能会减慢开发过程。
Git Flow是一种非常流行的Git分支管理模型，但作者也说明它并不是"万能药"。如果您的团队正在进行软件的持续交付，我建议采用更简单的工作流程（例如GitHub flow），而不是尝试将 git-flow 硬塞到您的团队中。
（二）GitHub Flow
1、概述
GitHub Flow是由GitHub推广的一种简单、敏捷的Git工作流程，旨在支持持续交付和快速迭代。它适用于小型团队和Web应用开发，强调频繁的部署和紧凑的开发周期。在本文中，我们将深入了解GitHub Flow的特点、优势以及如何使用它来实现高效的开发流程。
2、分支
GitHub Flow是GitHub使用的分支策略。不过，您不必使用 GitHub 即可使用此分支策略。
https://www.alexhyett.com/git-flow-github-flow/
GitHub Flow只有两个主要分支：
- master：主分支，存放生产环境的代码。
- feature或fix：功能或修复分支，用于开发新功能或修复Bug。
对于 GitHub Flow，一般流程如下：
- 创建功能分支： 从master分支创建一个新的功能分支，命名为具有描述性的名称，如feature/add-login-page。
- 开发和提交： 在功能分支上进行代码开发，通过频繁的提交保持代码的小步快跑。确保每次提交都是一个逻辑上完整的改动。
- Pull Request（PR）： 当功能开发完成并通过本地测试后，创建一个Pull Request（PR）。在PR中描述功能的目标和实现方法，请求其他团队成员进行代码审查。
- 代码审查： 团队成员对Pull Request中的代码进行审查。代码审查有助于发现潜在问题、提出建议和确保代码质量。
- 合并到主分支： 经过代码审查并通过测试后，将功能分支的更改合并回master分支。
- 部署和发布： 将master分支的代码部署到生产环境，进行实际发布。
- 删除功能分支： 一旦功能分支的更改成功合并到master分支，并且不再需要，可以删除该分支。
3、优缺点
优点：
- 简洁性：GitHub Flow简单明了，易于遵循，适用于小型团队和采用持续交付实践的项目。
- 持续交付：专注于持续交付，鼓励频繁部署和快速迭代。
局限性：
- 缺乏版本管理：GitHub Flow不显式处理版本控制，不支持在生产环境中维护多个版本，这可能是某些项目的局限。
- 潜在不稳定性：持续交付可能导致频繁部署，可能在生产环境中引入不稳定性。
GitHub Flow是一种简洁、敏捷的Git工作流程，强调持续交付和频繁部署。它适用于小型团队和Web应用开发，有助于团队快速交付高质量的代码。通过从master分支创建功能分支、频繁提交、代码审查和持续部署，GitHub Flow为团队提供了高效、流畅的开发流程。当团队追求敏捷开发、持续交付和快速迭代时，GitHub Flow是一个值得尝试的工作流程选择。
如何选择？
Git Flow适合以下情况：
- 您的项目需要显式版本控制和正式发布。
- 您需要在生产环境中维护多个版本。
- 您的团队具有管理多个长期存在分支的经验。
GitHub Flow适合以下情况：
- 您的团队实践持续交付，重视频繁部署。
- 您的项目较小，不需要显式版本控制。
- 您更注重简单和敏捷的开发流程。
（三）Gitlab flow
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 http://Gitlab.com 推荐的做法。
1、 上游优先
Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。
Chromium项目就是一个例子，它明确规定，上游分支依次为：
- Linus Torvalds的分支
- 子系统（比如netdev）的分支
- 设备厂商（比如三星）的分支
2 、持续发布
Gitlab flow 分成两种情况，适应不同的开发流程。
对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。
开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
3、 版本发布
对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。
以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
（四）适配版
1.分支说明
分支主要分为几大类：需求分支（feature）、测试分支（dev\sit\uat）、预发布分支（release）、生产分支（master）、生产修复分支（hotfix）。
- feature分支
feature分支为需求分支，每个需求对应一个feature分支，开发人员在feature分支进行代码提交。需求分支基于master分支拉取创建。
分支命名规则：feature_分支上线时间_需求编号。需求编号为架构师或者项目经理分配。
分支创建时间：年月日
dev分支：dev分支为开发自测分支
sit分支：sit分支是联调环境的测试分支，测试分支不允许进行代码修改，测出缺陷后在feature分支上进行修改，修改完成后由配置管理人员合并feature分支至sit分支。
分支命名规则：sit_分支创建时间_需求编号。涉及多个需求的时候需求编号进行追加。
uat分支：同sit分支。
release分支：release分支为预发布分支，对应准生产环境。生产验证通过则merge到master分支。验证过程中发现缺陷，在feature分支进行代码修改，修改完成后合并到测试分支进行验证，验证通过后merge到release分支进行验证。
分支命名规则：release_分支创建时间_需求编号。涉及多个需求的时候需求编号进行追加。
master分支：release分支验证通过则merge到master分支并打标签记录版本号（与上线版本号一致），设置master分支无法提交。Master分支只能从release分支合并，不允许在该分支进行代码修改。
hotfix 分支：hotfix分支为生产缺陷修复分支。当业务进行生产环境验证，发现bug时基于master分支拉取hotfix分支。修复完成后部署在预生产环境进行验证，验证完后merge到master分支进行投产打包。
在生产环境验证完成后，将本期上线的所有feature和release全部删除，并将master分支合并其他费master分支
2.常规需求开发分支
当有新需求时根据需求创建对应的feature分支，用于开发人员进行功能开发。之后进行功能上各个测试环境的验证，产生冲突后在环境分支接近冲突，例如是sit环境冲突，就在sit分支上解决，但是操作手法上可以先创建一个sit的临时分支，在sit临时分支解决完冲突后发布，发布成功再合入sit分支再发布一次，保证环境的稳定性。此处没用cherry-pick用merge是为了简化操作。
3. 多需求开发分支
当多个需求同时进行开发测试时按照图上顺序依次进行分支拉取。
与单需求的区别在于测试分支先基于master拉取再merge各个需求分支。
（五）AoneFlow
1.简介
阿里的git工作流；3类分支（master、特性分支、发布分支），1个主分支（master）
2.分支管理
规则一，开始工作前，从master创建feature分支。
从代表最新已发布版本的master分支上创建一个通常以feature/前缀命名的特性分支，然后在这个分支上提交代码修改。也就是说，每个工作项（可以是一个人完成，或是多个人协作完成）对应一个特性分支，所有的修改都不允许直接提交到master分支。
规则二，通过合并feature分支，形成release分支。
从master分支上拉出一条新分支，将所有本次要集成或发布的feature分支依次合并过去，从而得到release分支。release分支通常以release/前缀命名。
规则三，发布到线上正式环境后，合并相应的release分支到master分支，在master分支上添加tag，同时删除该release分支关联的feature分支。
为了避免在代码仓库里堆积大量历史上的feature分支，还应该清理掉已经上线部分feature分支。如果要回溯历史版本，只需在master分支上找到相应的版本的tag即可。
3.评价
AoneFlow 的发布分支是相对固定的，因此相比 GitFlow 更易于进行持续集成。
经过阿里团队长期实践，稳定性很高。项目管理相比却更加容易和高效，去除一些繁琐步骤。
每次有新需求时，从当前主干分支拉取一个特性分支。多个特性分支可同步开发，到发布时间节点时，根据不同的环境合并不同的分支。
对于维护不同环境和不同版本的情况下非常适用，不会产生多余的分支，主干分支与线上环境保持一致。
• 优点：灵活的安排发布分支，支持长时分支；
• 缺点：有长时分支，就会有冲突。
（六）Commit规范
Commit格式
Type（提交类型）：
- feat：新功能（feature）
scope写明新功能涉及到的交易或功能。
subject应包含功能对应的上线版本及功能点。
示例：增量三-20230401-需求名称
说明：新需求能单个需求一次提交的话尽量一次提交。
- fix：修补（bug）
scope写明缺陷修复涉及到的交易或功能。
subject应包含缺陷对应的缺陷编号。
body写明本次缺陷细修改思路。
说明：缺陷修改时一个缺陷一次提交，尽量不混合提交。
- docs：文档（更新README.md文档或注释）
- style：格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
subject应包含优化需求的上线版本及需求名称
- test：测试
- build： 影响编译的一些更改，比如更改了maven插件、增加了npm的过程等
- ci：持续集成方面的更改。现在有些build系统喜欢把ci功能使用yml描述。如有这种更改，建议使用ci
- chore：其他改动。比如一些注释修改或者文件清理。不影响src和test代码文件的，都可以放在这里
- revert：为了撤销之前commit的提交
Scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。如果你的修改影响了不止一个scope，可以使用*代替。
Subject是 commit目的的简短描述，不超过50个字符。
Body部分是对本次 commit 的详细描述，可以分成多行。与插件中 Long description 作用一致。
硬性校验：每次提交不少于10个字符；
推荐使用git commit template。
可以参考：idea --Git Commit Template插件的使用-CSDN博客、一文弄懂 Gitflow、Github flow、Gitlab flow 的工作流 - 知乎 (zhihu.com)、如何制定适合团队的Git工作流、分支管理最佳实践 (zhihu.com)、Git 工作流程 - 阮一峰的网络日志 (ruanyifeng.com)、困在分支迷宫？Git分支管理大对决：Git Flow vs. GitHub Flow，谁更适合你的团队？ - 知乎 (zhihu.com)、大厂git分支管理规范：gitflow规范指南 - kevin_ying - 博客园 (cnblogs.com)