[toc]
前言
接触gitlab大约两年,最初是公司管理代码需要,平时用到的就只是基本的拉取和提交,配合着tortoisegit软件使用,基本满足日常需求。一直以来也没有研究过,近来才了解到gitlab的milestone和issues功能,正好部门也有这方面的需求,于是上网搜了些资料,大体整理了下其使用过程,以作记录。
简单说来其实就是用milestone标识阶段目标,对阶段性目标进行细化,化整为零成一个个的issues,然后我们就可以根据每个issues的紧急程度选择性的完成,等所有issues解决完之后我们的阶段性任务也就完成了。
用处
- 领导可以通过issues了解部门每个人当前的工作以及后期的工作计划;--我们要习惯将正在解决和计划要解决的问题都转换为对应issues。
- 可以协助我们将项目细化成一个个子任务,并且可以清晰的查看项目进度;--milestone对应着阶段性项目计划,然后细分为多个issues,而且可以指定完成时间,gitlab会自动生成完成进度情况概略图。
- 可以提供一个讨论平台,开始解决问题之前先讨论,确定方案后有助于更高效地解决问题;--issues并不一定是一个要解决的问题,也可以是一个建议,大家可以一起讨论。
- 可以到处milestone和issues记录,整理产品文档。--milestone和issues建立时我们通常会对问题进行简单描述,并且记录问题的解决过程,包括他人提出的疑问也可以在这里记录,后期可以随时查看。
功能说明
新建milestone(里程碑)
比如某个省份的新需求、某个功能子模块、新的项目等,可以创建一个里程碑,作为最终的项目目标。
-
新建里程碑很简单:
- 创建一个名字;
- 然后对其进行简单的描述,比如创建它的原因、这个里程碑的最终目的等,编辑的时候可以直接贴图,也可以添加附件;(支持markdown格式,可以预览)
- 指定计划的完成时间。
可以在项目开始前创建里程碑,后面建议题时关联它;也可以先建议题,后期由项目负责人建里程碑,然后把所有议题关联过来。
新建issues(议题)
-
一个议题表示一个功能、一个bug、一个建议;
- 功能:里程碑的细分,尽量小,方便merger时的代码审核;
- bug:解决程序中存在的某些问题;
- 建议:可以作为一个讨论交流区,也可以实现它。
新建议题很简单,标题+描述+计划时间+指定人+里程碑,里程碑一定要指定一下,还可以加标签。
创建分支
可以在议题下直接创建,也可以在本地创建后推送。
-
在议题下创建
- 新建分支
- 新建合并请求及分支
它们的区别:
- 其实没啥区别,就是一个是开发完了之后再提交merger请求;一个是先创建merger请求,但是还不能merger,等开发完之后启用merger请求之后才能merger。
创建说明
- 默认的名字是issue号+issue标题中的英文字符;
- 选择基于哪个分支创建。输入首字母会有提示,根据提示输入完整的分支名,然后创建。(如果没有完整输入分支名的话会创建失败)
-
在本地创建
- 也可以直接在本地自己新建一个分支,开发完之后推送,然后合并。
- 这样的话不会自动关联issue,但是可以通过在提交日志中引用issue来关联,方法是 #+issue号。
本地开发
小乌龟删除本地分支的方法
-
步骤如下:
-
如果没有此菜单就设置一下:
merger请求
- 每个issue都新建一个分支,多人开发时会有很多分支,在merger之后这些分支就没用了,所以可以在创建merger请求时选择“合并后删除源分支”。
Git工作流
- 集中式工作流
-
便于快速开发。
基于里程碑新建一个分支,此分支没有权限,所有组员都可以直接提交,省去merger过程,开发快。
每个功能的实现都新建一个issue,但是不用再创建新的分支进行开发,只是在每个issue开发的提交日志中关联一下issue即可。(要记得关联issue)
麻烦点的也可以新建分支然后字节merger。
-
Git-flow工作流
可以用于整个工程的版本维护。
- 两个主要分支:master分支和develop分支。
- 有新的需求时(新建一个里程碑),基于develop创建一个分支(feature分支),在此分支上开始创建议题进行开发,开发完之后合并到develop分支。(feature分支开发时根据实际情况选用集中式开发、Git-flow和fork工作流)
- 如果功能开发完了,需要提交一次测试,那么就基于develop分支创建一个新分支(release分支)然后提交测试,测试完成后将release分支合并到master分支。
- 如果master分支在现场运行中出现了问题,需要修复,那么就直接基于master分支新建一个hotfix分支进行问题修复,改完后合并到master分支和develop分支。
- fork工作流
- 通常是开源代码选用的方式,缺点是提交merger请求后不能拉取新修改的内容,不方便代码审核。
使用方法
建里程碑;
建议题;
-
如果采用集中式工作流:
- 开发人员在本地建分支进行开发(注意提交时关联议题#issues);
- 直接推送。
-
如果采用git-flow工作流:
- 在本地创建分支提交,或者在issues下创建分支拉取;
- 开发完提交,然后创建merger请求。