一、Git工作流
1、开发流程
在master分支或功能开发分支切出个人开发分支推荐命名规则：[开发者姓名简拼]/[类型]-[命名]，
开发者姓名简评有冲突可后缀添加工号
类型包括：fix/fixbug、feat/feature等，
命名可以自定义，推荐
有jira的使用jira-[JIRA_ID]
有confluence，使用confluence-[confluence_pageId]
其他逻辑相同
功能开发完毕后提交并推送个人分支至远端
本地切换到dev分支并更新 git checkout dev && git pull，合并个人远端开发分支。注：至于使用git pull 还是 git featch，可参考此图
解决冲突后推向远端dev分支 git push origin dev
若gitlab-CI配置正确，提交dev分支/任何分支创建特定tag（test-xxxxx） 会自动触发 CI、CD 流程
测试环境通过后，在本地自己开发分支合并master分支
解决冲突后，push代码至自己远程的开发分支
在gitlab提交merge request，目标分支为master，@相关人员review代码，确定无误后，负责人合并MR
在Gitlab中在master分支创建tag（release-xxxx），触发CI构建正式环境包
在http://web.xxxx.com/提交部署申请，待申请通过后会自动部署至生产环境
在整个研发流程中，
部署测试环境可一键完成，即 push至远端特定测试分支 或 任何分支创建特定tag并push到远端
部署生产环境增加review code步骤及部署审核步骤
项目中启用CI/CD后，在有效利用了Gitlab的功能的同时，保证了项目的稳健和减少了繁琐的执行流程。
2、注意事项
merge冲突只能在本机执行，只可以合并远程分支到自己的开发分支
所有被合并到 “master” 分支的代码都必须保证正确！它们的代码必须被检验过和确认过。这也意味着，开发工作不应该直接在 “master” 分支上进行，这也是一个最基本的准则。
功能开发分支生命周期只维持到这个开发主题的结束之后（例如当错误被修复，新功能被完成……），这个分支的改动就会被合并到项目的master中去，并且这个分支也会被删除掉。
rebase 会改写历史记录，因此你应该只使用 rebase 来处理你的本地分支，千万不要对已经被发布的提交进行这个操作。
用 “git commit” 命令，并附带上 “–amend” 参数，可以轻松地来修改你的最后一次提交，包括修改提交信息和添加新的提交，注意：此方式需要commit没有被push到远程仓库
3、紧急上线
master分支检出代码 git checkout master && git checkout -b hotfix/XXXXX
修复问题 合并到dev进行测试
测试完毕在Gitlab中提交MR，review后再合并到master上线
4、Git提交信息格式规范
提交消息由一个信息头、主体（body）和页脚（footer）
信息头部包括：
类型（type）、范围（scope，可选）、主题（subject）
[()]:
[BLANK LINE]
[body]
[BLANK LINE]
[breaking changes]
[BLANK LINE]
[footer]
信息头是唯一强制提交的
第一行（类型+主题）仅限于50个字符（强制）
其他部分应限制在72个字符内（包括换行）
这可以让提交信息更容易在Gitlab以及各种git工具中阅读。
type可选值：
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 文件的格式变动（例如，lint执行后的变动等，不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
ci：CI发布流程改变
scope：提交影响范围
subject：对提交的描述
body：对提交详细的描述
footer有两种功能：
1、不兼容变动：如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。
2、关闭Issue：如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。关闭方式可看下文中的Gitlab 相关名词Issue描述
示例：
1、feat(classroom): 一个新功能
2、ci: 添加测试
3、style: 移除多余空格
二、Gitlab使用原则
1、上游优先
Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有master分支采纳的代码变化，才能应用到其他分支。
2、持续发布
对于"持续发布"的项目（多环境的分支工作流），Gutlab建议在master分支以外，再建立不同的环境分支。比如：
"开发环境"的分支是dev
"预发环境"的分支是pre
“生产环境"的分支是master
“生产环境"的分支是预发分支的"上游”，
预发分支又是开发分支的"上游”。
代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，在Gitlab中新建ISSUE（假如，ID为312），描述问题，然后从master新建一个修复分支fix/312，处理完问题后，提交commit message为fix([scope]): Fix #312，然后把它合并到dev，确认没有问题，再cherry-pick到pre，这一步也没有问题，才合并进master，流程也就是：dev -> pre -> master。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
三、Gitlab相关名词
1、Issue
Issue 用于 Bug追踪和需求管理。建议先新建 Issue，再新建对应的功能分支。功能分支总是为了解决一个或多个 Issue。
功能分支的名称，可以与issue的名字保持一致，例如：15-require-a-password-to-change-it
开发完成后，在提交说明里面，可以写上"fixes #14"或者"closes #67"。Gitlab规定，只要commit message里面有下面这些 动词 + 编号 或 ，就会关闭对应的issue。
Close, Closes, Closed, Closing, close, closes, closed, closing
Fix, Fixes, Fixed, Fixing, fix, fixes, fixed, fixing
Resolve, Resolves, Resolved, Resolving, resolve, resolves, resolved, resolving
可以有两种方式：
1、都在同一个仓库：
Closes #333, #444, #555 and #666
2、在不同的库：
Closes #333, #444, and https://gitlab.com///issues/
2、Protected branch
master分支应该受到保护，不是每个人都可以修改这个分支，以及拥有审批 Merge Request 的权力。
3、Merge Request
功能分支合并进master/feature分支，必须通过Merge Request，Merge Request本质是一种对话机制，你可以在提交的时候，在评论中@相关人员或团队，引起他们的注意。
4、Merge节点
Git有两种合并：一种是"直进式合并"（fast forward），不生成单独的合并节点；另一种是"非直进式合并"（none fast-forword），会生成单独节点。
前者不利于保持commit信息的清晰，也不利于以后的回滚，建议总是采用后者（即使用–no-ff参数）。只要发生合并，就要有一个单独的合并节点。
5、合并（Squash）多个commit
为了便于他人阅读你的提交，也便于cherry-pick或撤销代码变化，在发起Merge Request之前，应该把多个commit合并成一个。（前提是，该分支只有你一个人开发，且没有跟master合并过。）
也可以采用rebase命令附带的squash操作