目前team中的代码管理规范，分享一下

一、版本管理工具
git

二、分支说明
2.1 master分支

master属于生产稳定主分支，所有版本迭代上线后，代码变动最终都需要合并至主分支的代码中。主分支上的代码每次被更新，都应有对应的标签(TAG)。

2.2 feature分支

feature属于产品规划的版本分支，是多个dev分支小组的合集，由dev合并生成。是正常产品版本提测时的分支，供测试人员在测试环境测试。

命名风格：feature+产品版本号
命名举例：featureV2.1.0

2.3 dev分支

dev属于各开发人员的独立分支，从master拉取作为开发的基础版本。

命名风格：dev+开发人员缩写+开发内容简要
命名举例：dev_yq_分库分表、dev_whn_银联二三类、dev_wjl_日志优化

2.4 hotfix分支

hotfix属于线上BUG紧急修复的补丁版本，从master拉取作为开发的基础版本。是补丁修复版本提测时的分支，供测试人员在测试环境测试。

命名风格：hotfix+补丁日期
命名举例：hotfix-Patch20191002

三、开发上线流程

3.1 流程图

3.2 流程说明

1.开发人员根据各自的开发需求，从master拉取分支，独立开发

2.提测时，根据产品版本内容规划，将相应的dev分支合并，生成版本分支featureV2.1.0

3.测试人员测试正常版本featureV2.1.0

4.测试期间，遇到生产环境问题，需要紧急发版，从master拉取分支，修改相应的代码，

命名hotfix-Patch20191002，以hotfix-patch20191002提测发版

5.hotfix发版后，将代码合并入master，并在master打标记(TAG)，删除hotfix分支

6.featureV2.1.0回归测试前，再一次将master合并入分支，做回归测试

7.featureV2.1.0测试完成后，以featureV2.1.0发版，发版完成后，将代码合并入master，并在master打标记(TAG)，删除featureV2.1.0分支及涉及的dev分支

代码管理和版本管理的作业流程以及规范是怎样的？ 

代码管理和版本管理的作业流程以及规范是怎样的？下面以文档的形式进行详细分析，希望能够给予测试人员一些帮助和指导。

本文目的

本文试图提供一套有效进行代码和版本管理风控的标准、约定和指导。本文以安全可靠的软件工程原则为基础，在源代码层面使其易于管理、维护，同时降低核心技术泄密风险，在版本管理层面，保证每个交付前、交付中、交付后的产品版本是一致的，且可快速、准确的对每个版本中的过程情况进行追溯。本文以通过遵循和不断改进项目过程中的实施标准，使各项目产生的代码有更好的管控机制，降低代码泄密风险、降低发版风险并提高软件开发团队的生产效率。

本文适用于人群

本文档的预期读者包括项目开发组全体成员：产品人员、技术管理人员、系统设计人员、系统开发人员、系统测试人员、系统维护人员、推广培训人员及其他相关人员。

使用范围

本文档适用于所有与代码管理、版本控制相关的项目管控工作。

一、管理工具

1、代码管理工具Git

Git是一款免费、开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。它是目前世界上使用最广泛的代码管理工具之一，包括Google、Facebook、Microsoft、Twitter等在内的大型企业都在使用他进行管理。Git在本规范中主要用于代码管理与开发版本控制。

2、版本管理工具Maven

Maven是一个软件项目管理及自动构建工具，由Apache软件基金会所提供。Maven在本规范中主要用于版本号管控以及代码部署的自动构建。

3、发布管理工具Jekins

Jenkins是一个用Java编写的开源的持续集成工具。它主要用于持续、自动地构建/测试软件项目。Jenkins在本规范中主要用于系统的自动构建与发布以及发布后系统运营的监控管理。

二、版本管理

1、版本命名规范

版本命名包含：主版本号、次版本号、修正版本号、里程碑版本号。例如：2.2.0.Beta2，该版本号代表主板本为2，次版本为2，修正版本无，且为发布的第二个公测版本。

具体的各版本号的作用如下：

2、版本管控流程

在产品立项时，一般由产品经理或项目负责人明确项目版本号，其至少包含主版本号和次版本号。

开发、测试、发版过程中需严格遵循版本号的约束进行版本管控，主版本号和次版本号一旦制定，就不允许修改，除非重新立项。修正版本号可在开发过程中进行约束，但尽量提前进行约束且尽可能在开发过程中不做调整。

版本发布时，一般由产品经理或项目负责人指定里程碑版本号。程碑版本号可以跳版本进行发版，也可以无中间版本号。比如，可以直接发布beta(公测版)或者GA(正式版)，但尽可能遵循里程碑版本顺序进行发版和版本管控。

三、代码管理

1、角色

代码管理主要分三大角色：系统管理者、项目管理者、部署者、开发者。系统管理者负责创建新项目、权限分配、用户增加删除和代码库备份。项目管理者负责对具体的某一个项目的权限分配，代码管理。部署者负责对测试代码和正式代码进行发版部署。开发者负责从项目分支代码进行代码开发。

2、权限

管理Git、Maven、Jenkins的各个角色的权限如下：

3、代码管控流程

1）若为新项目，则由系统管理者通过操作Git创建项目工程，并将Git的项目管理权限赋予项目管理者，且交由项目管理者进行项目与代码管控。

2）项目管理者通过操作Git在主干代码库基础上创建开发代码库，并将分支代码的操作权限赋予部署者和开发者，同时通过Maven约束版本号。

3）开发者基于开发代码库进行代码的开发与合并，并提交测试部署。

4）测试期间，部署者通过操作Jenkins将开发代码库的代码发版部署到测试环境，以供测试者进行测试。

5）测试通过后，由项目管理者通过操作Git将开发代码库代码合并到主干代码库。

6）发版上线时，由部署者通过操作Jenkins将主干代码库的代码发版部署到正式环境。

7）系统管理者定期对代码库进行备份。

代码管控的具体流程如下图：

一、版本管理流程

1. 主干分支（main）: 研发的分支从主干检出、经过测试（UAT）验收后必须要合并到main分支上，并且需要发布到UAT环境上再次验收，方可发布， 此分支名称固定为main，每个业务线只存在一个。

2. 功能分支（feature）: 需求研发、功能迭代、缺陷修复、处于研发中的分支。此分支名称按版本规范命名， 每个业务线允许多个存在。

3. 测试分支（uat）: 发布到测试环境的分支，任何研发修改，都需合并到此分支进行测试验证。 此分支名称固定为uat，每个业务线只存在一个。

二、各业务线运作规范

1. 每个业务线包含自己的main、uat和feature分支， 例如：

   国内业务：
   1） main 分支： main_china
   2) feature分支： internation_1.0.0_SNAPSHOT
   3) uat分支： uat_internation

   国际业务：
   1） main 分支： main_internation
   2) feature分支： internation_1.0.0_SNAPSHOT
   3) uat分支： uat_internation

2. 如果各业务线有共性需求，处理流程：

   国内业务的 china_1.1.0_SNAPSHOT -> 合并至国际业务的uat_internation -> 验证后合并至国际业务的main_internation (从china_1.1.0_SNAPSHOT 合并)

三、版本命名规范

1. 完整版本格式

   主版本号.次版本号.修订号-版本类型 【eg: 1.0.0-SNAPSHOT】

2. 主版本号： 项目级主导的规划实现。

   对应：项目级需求【eg: 1.0.0-SNAPSHOT，2.0.0-SNAPSHOT … X.0.0-SNAPSHOT】

3. 次版本号：功能性的新增与修改。

   对应：功能级需求 【eg: 1.0.0-SNAPSHOT，1.1.0-SNAPSHOT … 1.X.0-SNAPSHOT】

4. 修订号：面向问题的修正处理。

   对应： BUG级缺陷修复【eg: 1.0.1-SNAPSHOT，1.0.2-SNAPSHOT … 1.0.X-SNAPSHOT】

5. 版本号名称说明：

   1）SNAPSHOT : 快照版本，标识处于研发阶段，该版本可能存在未完成的功能或还需修复的bug，概念上对应dev分支。

   2）HOTFIX：修复版本， 针对临时缺陷或生产问题修复。

   3）BETA：测试版，发布测试的版本，概念上对应uat分支的测试。

四、版本合并管理规范

合并原则：

1. 开发分支（feature）都是基于主干分支（main）检出。
2. 开发分支（feature）可以合并至UAT分支进行测试， 验收成功后可以合并至主干分支（main）回归。
3. 测试分支（uat）不可以合并至其他任何分支， 验收后的分支，通过开发分支（feature）进行合并。

合并权限管控

1. 权限合并至允许负责人操作， 研发人员不能直接操作，负责人通过gitlab管控好权限。
   

2. 涉及到合并处理的两个环节， 一是提测时的合并， 二是测试通过回归验证的合并， 负责人必须做好审核， 避免代码合并出现的版本错乱与多模块关联性问题。