研发版本控制流程规范
简介
项目版本控制采用git,git账号向运维申请
学习资料
Git 在团队中的最佳实践--如何正确使用 Git Flow - wish123 - 博客园
Git 仓库地址
分支管理
在一个开发周期内正常维持三个主要分支，develop、release、master.
分支目录：
最高目录层级应该只存在develop,master分支,
其它release,hotfix,feture都应该在对应的/release,/hotfix,/feature目录下（使用GitFlow），
如果存在其它单独主线分支,例如稳定版本master分支、私有云项目分支,可以存在最高目录层级,
但分支名称需要标注清楚如:master_stable,master_copyright等
develop 【开发分支】
所有新开发的任务都需要按任务粒度从develop分支拉取应的feature分支进行开发,
开发人员在feature分支完成对应任务的研发、测试流程后，如果该任务需要在当前批次提交测试，
则合并到develop分支，提交给测试人员进行测试，测试人员在develop分支进行测试，
本批次开发任务全部提交到develop分支、测试通过后会从develop分支切出release预上线分支进行回归测试。
develop分支不应该被提交未经测试通过的代码.
release 【预上线分支、测试分支】
预发布分支是从develop拉出来的，流程结束会合并到develop和master分支。
该分支是为方便测试人员拉的分支，每周更新一次，release后面跟的数字为上线日期（例如：200423）。
测试期间release分支如果发现问题需要开发修正,请开发在对应需求的开发feature分之修正完毕、自测无误后遴选(cherry-pick)对应的代码到release.
注：新建release的时候本地有一个release的分支，则需要先删除才可新建，建好release后还需要push一下才会推送的远端仓库。
master 【生产分支】
该分支的代码只能通过release或hotfix合并过来，不可直接在此分支上进行开发，且所有合并过来的代码必须是经过测试通过的。正常迭代任务请使用release，紧急修复的BUG使用hotfix。
严禁:
1. master 分支不允许提交未经测试或者不需上线的代码.
2. master 分支不应该发生代码回滚(revert、reset)操作.
feature 【功能分支】
当每周一开始开发新的需求任务时,从develop拉取新的feature分支,在此分支上完成该开发任务的所有代码修改,推送远程,需要提测的时候手动合并到develop分支。
命名规范：
以上线批次日期（年月日，年份只有2位）+ 任务编号 + 开发姓名简拼 + 描述命名
例如："feature/200423_00009_LJP_缓存优化功能"
不确定上线日期的请修改上线日期为“future”
例如："feature/future_00009_LJP_缓存优化功能"
PS:如果只需要提交SQL、配置脚本,不需要单独拉去feature,自测通过后提交到release对应目录即可
注：
1.开发人员每天需要将更新的develop代码合并下到自己的还存在的feature上,保持feature分支代码更新
3.feature分支只允许从develop分支切出，只能合并回develop分支
hotfix 【补丁分支】
该分支是从master拉出来的，流程结束合并代码到master和develop分支，release则需要手工cherry-pick(遴选)。
命名规范：
以上线批次日期（年月日，年份只有2位）+ 任务编号 + 开发姓名简拼 + 描述命名
例如："hotfix/200423_00009_LJP_缓存优化功能"
不确定上线日期的请修改上线日期为开发日期
例如："hotfix/200414_00009_LJP_缓存优化功能"
上线流程
每周四上午将本次release合并到master（需打tag），master分支回归通过后正式上线发版.
例如：20200423周四早上，现有分支develop，release/200423，master
release/200423通过测试后,合代码时会把release/200423进行一个gitFlow的finish操作，代码则会自动合并到master和develop（有冲突需要自行解决）.
master分支进行最终回归流程，通过后正式发版到生产环境,
开发提供配置文档、SQL脚本，测试填写上线内容发起上线邮件申请，由产品主管、开发主管确认回复邮件后，抄送对应运维人员,运维人员收到邮件后,按照附件内容配置、执行脚本,最后发版,发版完成后回复邮件给测试、验收人员,生产回归、验收无误后回复邮件给项目运营人员.
此时开发用到的分支就变成了develop，release/200430，master，晚上发版master代码，下周四依次类推此操作.
当每周一开始开发新的需求任务时,从develop拉取新的feature分支,在此分支上完成该开发任务的所有代码修改,自测结束后提交到feature分支,推送远程,需要提测的时候手动merge到对应的release分支.
任务排期
以上面例子为基础，20200410周五会排期，批次为20200423
批次号为上线日期，预留一周开发时间，四天测试时间.
代码合并流程
1，更新develop、master、release为最新的代码
2，将master合并到release
3，完成release流程，会自动合并develop和master（有冲突解决冲突）
4，推送代码
5，删除本地release分支，然后新建一个release流程分支
6，推送最新的release分支到远程仓库
注：hotfix和release流程分支各只能有一个,所有hotfix、release、feature分支都必须以git-flow流程切出,hotfix、release以git-flow的finish按钮结束流程,feature手动合并到release.
脚本配置
脚本、配置提交规范
- DDL类型sql脚本，按照规范提交到项目对应flyway目录下，由flyway发版时执行。
- DML类型sql脚本，使用Archery-SQL审核查询平台，提交的脚本需要严格按照顺序提交，保证执行语法、结果无误。具体规范参见SQL审核平台教程。开发批次中的DML脚本，提测时提交到UAT环境、PROD环境。
- 配置文件提交到项目config/目录下，写清楚执行逻辑、顺序，由运维人员执行。
脚本命名(flyway 后期会上线,所有人严格遵守以下规范)
正常开发迭代，文件夹以上线日期命名
示例： db/migration/2020/0423
sql 脚本文件命名必须包含提交人和禅道编号/描述，以 sql 结尾，且得按最新的规范来命名
命名规则：前缀 + 上线日期（yyyyMMdd） + 2 位序号（01）+ . + 5 位任务编号(00001) + __(双下划线) + 提交人简拼 +__(双下划线)+ 描述 + 后缀(.sql)
前缀说明：V-新增，U-撤销，R-可重复执行。
注意！！！
一定是两个下划线 '__'
一旦脚本提交了，就不能删除和修改了，如果需要删除请使用 U 前缀，如果需要修改，请新加一个文件来处理，R 是每次都会执行的脚本，慎用。flyway 的使用方法是在运维打包编译的时候，就会去执行 flyway 的命令。修改文件名和修改文件内容都是属于变更了，执行会报错。
示例： V2020042301.00009__LJP__性能优化.sql
flyway 的版本是怎么比较的
举例：
V2020042301.00009LJP性能优化 A.sql
V2020042302.00007LJP性能优化 B.sql
以上 2 个文件版本的比较会变成 V2020042301.00009 和 V2020042302.00007，这样从左到右比对，所以后面的版本会比前面的大。
配置文件命名
命名规则：前缀 + 上线日期（yyyyMMdd） + 2 位序号（01）+ . + 5 位任务编号(00001) + __(双下划线) + 提交人简拼 +__(双下划线)+ 描述 + 后缀(.txt 等)
菜单配置，模板配置等以txt结尾
放置目录:config/2019/1116/2020042301.00009__LJP__性能优化.txt
示例：2020042301.00009__LJP__性能优化A配置.txt