从零开始devops-GitLab协作流程初稿

GitLab协作流程初稿

工作

准备工作

创建Groups组

PS：后续会将次流程在立项中自动进行。

一个项目立项，开始写代码建议建立一个项目组。

并设置权限

在设置界面创建Groups小组

Gitlab中的组和项目有三种访问权限

Private：只有组成员才能看到

Internal：只要登录的用户就能看到

Public：所有人都能看到

为project添加members

添加member

分配权限

进入Members选项卡添加成员到Groups组，添加信息包括（成员邮箱、权限、到期时间）权限分为五种，分别代表五种不同权限。 

Guest：可以创建issue、发表评论，不能读写版本库 

Reporter：可以克隆代码，不能提交，QA、PM可以赋予这个权限 

Developer：可以克隆代码、开发、提交、push，RD可以赋予这个权限 

Master：可以创建项目、添加tag、保护分支、添加项目成员、编辑项目，核心RD负责人可以赋予这个权限 

Owner：可以设置项目访问权限 - Visibility Level、删除项目、迁移项目、管理组成员，开发组leader可以赋予这个权限。

group,member与权限

如果你的group下面有多个project，比如有project1，project2，project3，而你的project1邀请了A和B，project2邀请了B和C，那么members A在自己的gitlab主页就可以看到project1，B可以看到project1和project2，C只能看到project2。如下图所示

GitLab Code Review机制

GitLab可以在分支合并的时候支持两种方式：

由Gitlab合并 （推荐）

注意是分支(new branch)不是fork

将源分支(Source branch)Push到远端，然后在GitLab指定目标分支（Target branch）发起Merge Request，对目标分支（Target branch）拥有Push权限的用户执行Merge操作，完成合并。

也就是说，使用GitLab进行Code Review就是在分支合并环节发起Merge Request，然后Code Review完成后将代码合并到目标分支。

优点：适合团队水平有差异的情况，如和外援共同开发，可以及时发现冲突，适合多人开发，可以用gitlab界面回滚，方便可视化的回滚与分析问题

缺点：有些情况会需要等待review确认

PS：gitlab ee支持多人reivew，gitlab ce支持单人review，后续会通过gitlab+gerrit解决多人reivew。

本地合并（不推荐）

在本地将源分支(Source branch)代码合并到目标分支（Target branch）然后Push到目标分支（Target branch）。

优点：适合单人开发或精英团队开发

缺点：多人开发冲突频繁，阻塞开发，不适合团队中有不熟悉git的开发的人，会有误操作，误删除分支错误合并的风险，适合团队人少且熟悉git。

主要操作步骤

设置保护分支

将master，develop，release设置为保护分支。

分支名称约定：

建立dev分支

需求确认后，从master创建develop分支

根据需求拆分分支

开发人员从develop分支创建自己的feature分支进行开发。

新建分支命名规则

人名（汉语拼音）/版本号/功能名称

例如：wangyuheng/1.0.1/makeLoginPanel

为什么这么命名？

git客户端可以折叠，多人开发方便查找自己的分支，可以尝试不这么命名会导致多人开发查找非常不方便。

为什么要根据功能进行拆分？

方便代码进行回滚和cherrypick，不要把多个功能写在一个分支不方便回滚代码定位问题。

建议建立功能分支后立即创建mr，并标记wip，当完成feature后移除WIP。

Source branch选择：wangyuheng/1.0.1/makeLoginPanel（功能分支）

Target branch选择：develop

feature合并前需要合并dev

feature分支合并到对应的develop分支之前，需要从develop分支合并到feature分支。相关人员进行代码reivew，点击accept触发merge，merge后触发pipleline自动打包。

定期合并master

master分支发生变更，需要从master分支合并到develop分支、可以考虑定期合并一次。

在提测节点合并到dev

feature分支合并到对应的develop分支之后，发布到测试环境进行测试。

提测后建立release分支

develop分支在测试环境测试通过之后，合并到release分支并发布到预发布环境进行测试。由测试确认提测成功。bug修改完毕以release进行发版。

新建release规则

人名release_版本号_日期

例如：release_1.0.1_20191230

为什么这么命名？

方便区分

修改bug分支命名规则

人名（汉语拼音）/版本号/问题_bugfix

例如：wangyuheng/1.0.1/问题_bugfix

为什么这么命名，git客户端可以折叠，多人开发方便查找自己的分支，可以尝试不这么命名会导致多人开发查找非常不方便。并标记bugfix。

发版本后, 在release分支改线上bug

release分支在预发布环境验证通过后，release分支合并到master分支并发布到生产环境。发版本后谨慎修改代码避免线上问题。发版后的bug需要多方确认谨慎修改。

线上bug，修改bug分支命名规则

人名（汉语拼音）/版本号/问题_hotfix

例如：wangyuheng/1.0.1/问题_hotfix

为什么这么命名，git客户端可以折叠，多人开发方便查找自己的分支，可以尝试不这么命名会导致多人开发查找非常不方便。并标记hotfix。

release禁止合入大规模改动，release代码合入应比dev严格，由架构师确认。

强烈建议使用版本号

版本号有利于回溯与二分查找版本之间的bug，也方便持续集成和持续部署

强烈建议规范合并分支流程

可以避免线上问题和回溯问题

参考

https://www.jianshu.com/p/8f392c57d72b?utm_source=oschina-app

https://www.cnblogs.com/ken-io/p/gitlab-code-review-tutorial.html

https://www.cnblogs.com/qianqiu-1026/p/8534897.html

http://www.fwhyy.com/2018/06/Use-the-Merge-Request-working-mode-in-GitLab-in-the-team/