一、分支及角色
1、Gitlab角色
Owner（拥有者）
项目所有者，一般负责分配权限。
Master（管理员）
由开发主管兼任，或者指定人员担任，负责合并release分支到master，merge申请可由开发人员发起，一般在上线第二天确认无问题后发起 merge申请。
Developer（开发者）
开发人员，负责feature、hotfix、release分支的创建，负责release分支的合并。
二、Git分支类型
master 分支（主分支）
主线稳定代码，所有分支都必须从master拉取。master设置为Protected，不允许Developer推送代码，只允许通过Master合并，并且只接受release分支合并请求。
feature分支（特性分支）
开发分支，由Developer从master创建，代码开发基本在该分支完成。
命名规则：feature-当前时间（年月日）-姓名简写_版本说明_版本号（可不用）
如：feature-20190920-whw_demo
feature-20190920-whw_demo_v1.0
hotfix 分支（热修复分支）
BUG修复分支，由Developer从master自由创建，线上问题一般通过该分支修复。
命名规则：hotfix-当前时间（年月日）-姓名简写_版本说明_版本号（可不用）
release 分支（发布分支）
上线分支，测试环境验证通过后，由Developer从master创建分支，每次线上发版都必须创建对应的release分支，由Developer合并待上线的feature或者hotfix至release。允许合并多个feature或者hotfix分支。
命名规则：release-当前时间（年月日）_版本说明_版本号（可不用）
三、分支规范
1、闭环
所有分支基于master新建 。保证分支来源纯正
所有上线分支都是通过release分支merge。
master只接受release分支合并请求。
Master是主线稳定代码，禁止随意merge代码，只接收release分支merge请求。这一点通过gitlab角色权限控制。
将master分支设置为：protected，只允许Master发起merge和push。
2、开发流程
补充更详细的流程
1、由Developer创建feature分支，一个迭代版本创建一个feature分支。
dev、test环境允许直接部署feature分支。
注：
1）如果在dev、test环境需要在同一时期部署多个feature分支，允许合并到dev或者test分支进行部署。
2）只允许业务分支合并到dev或test分支，不允许从dev或test分支合并到业务分支（避免代码污染）。
2、当测试环境验证通过后，由Developer从master拉取release分支。
Pre、Prod环境都是基于release分支部署。
3、由Developer合并feature分支到release。
release分支对应上线版本，如果某次上线存在多个feature分支，可以将多个feature分支合并到release分支一并上线。
注：
1）release分支接受feature、hotfix的代码合并，不允许直接合并test分支代码（避免代码污染）。
2）如果在pre、prod环境发现bug，需先修改feature或hotfix，验证通过后再合并到release分支。
4、Developer发起release分支合并请求，由Master合并到master分支。
项目上线验收完后，由Developer发起merge请求将release分支合并到master，同时通知Master（管理员）合并代码。
每次上线都会生成一个release分支，release是对应到每个上线版本，需要保存历史记录。为了方便选择分支，我们会定时清理过时分支。（如果分支太多，分支选择列表太长，不便于操作），但是我们又想保存更多的release记录，可以通过创建Tag实现。
注：
1）上线完成之后（2小时后），可以基于release分支打一个当前版本的tag，重大版本必须创建Tag。如：
3、BUG修复流程
1、由Developer创建hotfix分支，并且基于hotfix分支修复BUG。
2、当测试环境验证通过后，由Developer从master拉取release分支。
3、由Developer合并hotfix分支到release。
4、上线验收完成后由Developer发起release分支合并请求，由Master（管理员）合并到master分支。
注：该流程跟开发流程类似。
4、版本回退
如果某次上线版本存在重大BUG，需要回退代码版本，我们找到合适的release分支部署即可。
5、历史分支管理
随着项目持续演进，分支会越来越多，为了方便操作，我们需要对分支进行清理，一般保留最近5个分支。
Feature：
建议保留近5个分支。
或者也可以在上线完之后删除，由release分支记录版本记录。
Hotfix：
建议保留近5个分支。
或者也可以在上线完之后删除，由release分支记录版本记录。
Release:
保留近3个分支，其他历史记录可以通过Tag保存。
Tag：
Tag是永久保留的，为了保存上线历史，release分支上线完之后可以打一个tag，说明本次上线功能、版本等信息。
四、日志规范
每次commit都必须填写备注，建议格式：
feat:新功能
例如: feat:新增用户管理功能
fix:修复内容
例如: fix:修复用户导出的bug
refactor:重构内容
例如: refactor:重构UserServiceImpl
五、Jar版本管理
1、版本类型
1）SNAPSHOT
快照版本，用于开发测试阶段。
命名规则：大版本号.迭代版本号.备用版本号-SNAPSHOT
大版本号：第一位，从1开始
迭代版本号：第二位，从0开始
备用版本号：第三位，从0开始，非必须
如：
1.0-SNAPSHOT
1.0.0-SNAPSHOT
通常情况下采用2位编号即可，如果某个时期存在多个开发版本，可采用3位编号。
2）RELEASE
release版本，正式版本，一经发布不允许修改。
命名规则：大版本号.迭代版本号.备用版本号
大版本号：第一位，从1开始
迭代版本号：第二位，从0开始
备用版本号：第三位，从0开始，非必须
如：
1.0
1.0.1
通常情况下采用2位编号，如果发现某个release版本存在bug需要修复，可生成3位编号。
注：线上项目必须依赖release版本，禁止依赖SNAPSHOT版本。
2．版本升级
2.1、原则
Ø Jar升级必须升级版本号，不允许覆盖发布；
Ø 重大版本升级大版本号（第一位）；
Ø 功能迭代升级小版本号（第二位）；
2.2、流程
版本变更流程参照开发流程（3.2），在不同的阶段使用不同的版本号。
开发流程见图：
1、featrue开发阶段。
featrue开发阶段使用SNAPSHOT版本，根据当前版本号定义新版本号，通常使用2位版本号。
如：
当前版本号：1.0，新版本号：1.1-SNAPSHOT
当前版本号：1.0.1，新版本号：1.1-SNAPSHOT
如果当前存在多个featrue分支同时开发，可通过备用版本号（第三位）进行区分
如：
当前版本号：1.0，
分别定义版本号：1.1.1-SNAPSHOT、1.1.2-SNAPSHOT，用于不同的项目分支。
2、测试环境验证阶段。
1）如果不需要合并部署，直接使用featrue开发阶段定义的版本即可。
2）如果当前存在多个项目分支，需要合并到test分支部署，代码合并之后需要重新定义版本，可采用2位版本号重新deploy。
如：
假如存在：1.1.1-SNAPSHOT、1.1.2-SNAPSHOT
定义版本：1.1-SNAPSHOT，去除第三位备用版本号，重新deploy。
3、预发布环境验证阶段（release验证）
预发布阶段定义release版本。
1）根据master当前版本定义。
如：
当前版本号：1.0，新版本号：1.1或2.0，小版本升级使用1.1，大版本升级使用2.0；
2）如果已经deploy release版本，发现BUG需要重新deploy。
当前版本号：1.1，新版本号：1.1.1，通过备用版本号升级，多个修复版本以此类推。
3．版本历史
每次版本升级都需要在wiki记录最新版本信息，包括版本号、版本描述，创建时间。
网友评论