gitlab上milestone和issues的简单使用

[toc]

前言

接触gitlab大约两年，最初是公司管理代码需要，平时用到的就只是基本的拉取和提交，配合着tortoisegit软件使用，基本满足日常需求。一直以来也没有研究过，近来才了解到gitlab的milestone和issues功能，正好部门也有这方面的需求，于是上网搜了些资料，大体整理了下其使用过程，以作记录。
简单说来其实就是用milestone标识阶段目标，对阶段性目标进行细化，化整为零成一个个的issues，然后我们就可以根据每个issues的紧急程度选择性的完成，等所有issues解决完之后我们的阶段性任务也就完成了。

用处

1. 领导可以通过issues了解部门每个人当前的工作以及后期的工作计划；--我们要习惯将正在解决和计划要解决的问题都转换为对应issues。
2. 可以协助我们将项目细化成一个个子任务，并且可以清晰的查看项目进度；--milestone对应着阶段性项目计划，然后细分为多个issues，而且可以指定完成时间，gitlab会自动生成完成进度情况概略图。
3. 可以提供一个讨论平台，开始解决问题之前先讨论，确定方案后有助于更高效地解决问题;--issues并不一定是一个要解决的问题，也可以是一个建议，大家可以一起讨论。
4. 可以到处milestone和issues记录，整理产品文档。--milestone和issues建立时我们通常会对问题进行简单描述，并且记录问题的解决过程，包括他人提出的疑问也可以在这里记录，后期可以随时查看。

功能说明

新建milestone（里程碑）

• 比如某个省份的新需求、某个功能子模块、新的项目等，可以创建一个里程碑，作为最终的项目目标。

• 新建里程碑很简单：

  • 创建一个名字；
  • 然后对其进行简单的描述，比如创建它的原因、这个里程碑的最终目的等，编辑的时候可以直接贴图，也可以添加附件；（支持markdown格式，可以预览）
  • 指定计划的完成时间。

• 可以在项目开始前创建里程碑，后面建议题时关联它；也可以先建议题，后期由项目负责人建里程碑，然后把所有议题关联过来。

新建issues（议题）

• 一个议题表示一个功能、一个bug、一个建议；

  • 功能：里程碑的细分，尽量小，方便merger时的代码审核；
  • bug：解决程序中存在的某些问题；
  • 建议：可以作为一个讨论交流区，也可以实现它。

• 新建议题很简单，标题+描述+计划时间+指定人+里程碑，里程碑一定要指定一下，还可以加标签。

创建分支

• 可以在议题下直接创建，也可以在本地创建后推送。

• 在议题下创建

  • 新建分支
  • 新建合并请求及分支

  它们的区别：

  • 其实没啥区别，就是一个是开发完了之后再提交merger请求；一个是先创建merger请求，但是还不能merger，等开发完之后启用merger请求之后才能merger。

  创建说明

  • 默认的名字是issue号+issue标题中的英文字符；
  • 选择基于哪个分支创建。输入首字母会有提示，根据提示输入完整的分支名，然后创建。（如果没有完整输入分支名的话会创建失败）

• 在本地创建

  • 也可以直接在本地自己新建一个分支，开发完之后推送，然后合并。
  • 这样的话不会自动关联issue，但是可以通过在提交日志中引用issue来关联，方法是 #+issue号。

本地开发

• 小乌龟删除本地分支的方法

• 步骤如下：

  
  image

• 如果没有此菜单就设置一下：

  
  image

merger请求

• 每个issue都新建一个分支，多人开发时会有很多分支，在merger之后这些分支就没用了，所以可以在创建merger请求时选择“合并后删除源分支”。

Git工作流

1. 集中式工作流

• 便于快速开发。

  基于里程碑新建一个分支，此分支没有权限，所有组员都可以直接提交，省去merger过程，开发快。
  每个功能的实现都新建一个issue，但是不用再创建新的分支进行开发，只是在每个issue开发的提交日志中关联一下issue即可。（要记得关联issue）
  麻烦点的也可以新建分支然后字节merger。

2. Git-flow工作流
   可以用于整个工程的版本维护。

• 两个主要分支：master分支和develop分支。
• 有新的需求时（新建一个里程碑），基于develop创建一个分支（feature分支），在此分支上开始创建议题进行开发，开发完之后合并到develop分支。（feature分支开发时根据实际情况选用集中式开发、Git-flow和fork工作流）
• 如果功能开发完了，需要提交一次测试，那么就基于develop分支创建一个新分支（release分支）然后提交测试，测试完成后将release分支合并到master分支。
• 如果master分支在现场运行中出现了问题，需要修复，那么就直接基于master分支新建一个hotfix分支进行问题修复，改完后合并到master分支和develop分支。

image

3. fork工作流

• 通常是开源代码选用的方式，缺点是提交merger请求后不能拉取新修改的内容，不方便代码审核。

使用方法

1. 建里程碑；

2. 建议题；

3. 如果采用集中式工作流：

   • 开发人员在本地建分支进行开发（注意提交时关联议题#issues）；
   • 直接推送。

4. 如果采用git-flow工作流：

   • 在本地创建分支提交，或者在issues下创建分支拉取；
   • 开发完提交，然后创建merger请求。