Git分支操作规范.md

分支名称约定

环境分支

1.开发环境(DEV)：开发环境是开发工程师专门用于开发的服务器，配置可以比较随意，为了开发调试方便，一般打开全部错误报告。 2.测试环境(TEST)：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。 3.UAT环境：UAT，(User Acceptance Test),即用户接受度测试验收测试，所以UAT环境主要是用来作为客户体验的环境。 4.灰度环境(GARY)：是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。 5.生产环境(prod)：是指正式提供对外服务的，一般会关掉错误报告，打开错误日志。可以理解为包含所有的功能的环境，任何项目所使用的环境都以这个为基础，然后根据客户的个性化需求来做调整或者修改。

五个环境也可以说是系统开发的五个阶段：开发->测试->UAT->验收->上线，其中生产环境也就是通常说的真实环境。

分支管理规范

命名规范（建议不使用中文）：功能主分支：feature_版本号_预计上线日期_负责人_具体业务示例： feature_v1_1_20210101_azukin_xxx 修复bug分支： hotfix_版本号_预计上线日期_负责人_具体业务示例： hotfix_v1_1_20210101_azukin_xxx 参与角色： · 开发、组长、测试、产品、运维

角色Gitlab中的职责： · 开发：根据自己所做的功能，在本地创建feat分支 · 组长：根据排期创建dev[版本号]、pre[版本号]分支，并对dev、pre分支进行管理维护 · 测试：dev[版本号]分支开发完成，组长合并代码到test分支，测试仅对test分支进行测试，测试完成之后，通知组长将功能合并到pre[版本号] · 产品：在pre环境进行验收，验收通过通知组长。 · 运维：对pre环境、生产环境进行发布。

分支提交流程：常规提交：说明： 1.需求评审，经过排期后，组长/负责人以上个版本的tag为蓝本创建dev[版本号]分支。 2.开发人员以当前需求所在版本，从dev拉去代码，本地开辟功能feat分支进行开发。 3.开发完成之后push代码至dev环境，开发人员进行自测和前端进行联调。 4.提测阶段，组长将dev的代码合并到test分支，test分支不允许直接修改。 5.测试通过以后，通知组长/负责人将代码合并至pre环境，产品/业务方在pre环境验收，验收通过组长/负责人将pre分支合并至master分支。 6.上线完毕之后需要对上线的master打tag标记。 7.上线完毕之后，如果有在上线之前拉取的dev分支，需要将master代码合并至dev分支。 8.所有的代码修改都必须要从dev合并到test,不允许在dev以后的分支进行修改和提交。

线上BUG修复，紧急上线提交流程

线上bug修复，需要从线上master分支拉取hotfix分支。
bug修复完成之后，由组长/负责人将代码合并到test分支。
测试人员在test分支进行测试，测试通过后通知组长/负责人将代码合并到pre分支。
产品/业务方pre环境验收，验收通过通知组长负责人将代码提交到master
master上线后打tag标签。
将master代码合并到现在正在开发的dev分支中

Commit格式规范

commit -m “():”

格式说明： type：用于说明本次commit的类别，只允许使用下面7个标识 · feat:新功能（feature） · fix:修补bug · docs:文档（documentation） · style:格式（不影响代码运行的变动） · refactor:重构（即不是新增功能，也不是修改bug的代码变动） · test:增加测试 · chore:构建过程或者辅助工具的变动 Scope: 可选参数用于说明commit的影响范围，比如数据层、控制层、视图层等，视项目不同而不同

Subject: 是commit目的的简短描述，不超过50字符

以动词开头
第一个字母小写
结果不加（.）例如： feat:新增退费挽单跟进报表

将feature合并到master(dev)操作

#1 创建功能分支 
(master) git checkout -b feature
#2 功能迭代 
(feature) git commit ...

#3 合并最新主干代码 
(feature) git checkout master 
(master) git pull 
(master) git checkout feature 
(feature) git merge master

#----解决冲突
(feature) git commit 
#4 review，修改代码 
(feature) git commit 

#5 提交测试通过后，合并到主分支，先执行一遍第三步#3把提交合并成一个 
(feature) git checkout master 
(master) git merge feature --squash 
(master) git commit 
#----推送到远端，正常结束 
(master) git push origin
#6 最后删除feature分支
git branch -d feature

已经开发很多代码，但还不能commit，需要临时切换分支修改bug，使用stash

idea中在VCS -> Git -> Stash Changes…

#--- 临时接到修改bug任务
(feature) git stash # 暂存当前开发的代码，非提交
(feature) git checkout bugfix
#--- 修改bug
(bugfix) git commit ...
#--- 修改完成后切换回功能开发分支
(feature) git checkout feature
(feature) git stash list #显示暂存的存档
stash@{0}: WIP on dev: 6224937 add merge
(feature) git stash apply stash@{0}