Git分支管理备忘录
Gitlab分支命名规范
publish_v1.0.0_ddl- 发布分支 每次迭代开始建立publish发布分支，分支格式: publish+本地版本编号+本次迭代DDL日期 如: publish_v1.0.0_0509
master - 主干分支，每次public分支发布线上验收通过后，将代码merge_request到master，同时打上对应的tag
tag命名规范
格式：v1.0.0_ddl 前缀:与每次迭代编号一致 后缀:本次迭代的ddl日期
如：v1.0.0_20200509
如果当天有多次合并 master
列如：v1.0.0_20200509_01，v1.0.0_20200509_02 …后面的 01 累加
feature_user_day - feature特征功能分支，分支格式：feature前缀+用户+ddl时间 如: feature_edwin_0508
hotfix_user_day – 紧急处理分支，当publish发布后，线上需要紧急打补丁，可以从当前发布合并后的master分支fork一个hotfix分支做紧急修复，然后再发布，发布完成，线上验收通过后，再把本次hotfix分支分别merge_request到master和publish分支，同时master分支重新打tag
分支发布图示说明
-
publish发布分支
-
hotfix分支
注: hotfix作为线上问题紧急修复分支，用来修复线上出现的紧急问题，操作时直接从master主干fork出最新的代码到hotfix分支，修复完成后直接发布到FAT、UAT测试验证，
线上验收通过后立即将hotfix合并回master和publish分支，然后给master分支打上tag记录
操作流程 : feature_xxx_xxx → publist_xxx_xxx→ master → tag
首先项目owner负责从上一次发布后的最新master分支复制publish_xxx一个分支作为本次迭代的发布分支，一般为publish_xxx_xxx。
然后在开发人员根据的publish_xxx分支fork出本次的自己本次开发的特征分支feature_username_xxx，然后上进行开发和测试。
当所有功能开发完成且所有与本次发布相关的feature_username_xxx分支都merge到publish_xxx_xxx分支后，此时publish_xxx_xxx开始作为测试分支，不允许publish_xxx_xxx再接受新的功能分支的合并，
如果publish_xxx_xxx分支测试不通过，需要从publish_xxx_xxx分支上拉取新的代码merge回feature_username_xxx，然后进行开发和测试，修复完成之后再merge回publish_xxx_xxx分支验证
项目上线后，项目owner在gitlab页面提交merge request到发布分支master分支，需要添加详细描述，增加了什么功能或修改了什么bug，如果有jira地址可以附加上。
注意：
-
所有的代码，必须保证在开发环境中测试通过。
-
提merge request之前先合并其他人提交到publish_xxx分的代码，保证代码是最新的，如有冲突需拉上对应人一起解决后再提交。
-
每个merge request只做一件事，只更新一个功能。
-
不允许直接在master分支修改代码或不经过merge request提交的代码
项目负责人将提交的merge request合并到master分支，同时增加版本tag 如:v1.0.0_20200509
第一个迭代周期完成，再执行第1步操作
附: 常用git操作指令