怎样使用GitLab管理项目？_gitlab项目管理

1. issue 介绍

一般 master 分支默认是被锁住的，其目的是保护该分支。普通开发人员可以创建 issue 后建立对应的分

支然后去完成任务。完成issue 后便要合并分支，只需发送 merge request ,等待 owner 审核才能合并到

master 分支上。合并的过程中可能会出现代码冲突问题，而这个问题却交给了owner去处理，因为普通

开发人员没有权限。

Issue 指的是一项待完成的工作，通常与系统的改进有关，中文可以翻译为 问题 或者 事务。下面这些都

是 Issue的例子。

• 一个软件的bug
• 一项功能建议
• 一项待完成的任务
• 文档缺失的报告

每个Issue 应该包含该问题的所有信息和历史，使得后来的人只看这个 Issue，就能了解问题的所有方面

和过程。历史上，Issue 起源于 客服部门。用户打电话反映问题，客服就创建一个工单(ticket)，后续的

每一个处理步骤，每一次与用户的交流，都要更新工单，记录全部信息。这就是issue的前身。因此，

Issue 的原始功能是 问题追踪和工单管理，后来不断扩展，逐渐演变成全功能的项目管理工具，还可以

用于制定和实施软件的开发计划。

2. 创建 Issue template

在存储库的.gitlab/issue_templates/目录内创建一个新的 Markdown（ .md ）文件. 提交并推送到您的默认分支.

如果您的存储库中没有.gitlab/issue_templates目录，则需要创建它.

要创建.gitlab/issue_templates目录：

1. 单击master旁边的+按钮，然后选择New directory .

   首先进入到项目中

2. 在 .gitlab 目录下用同样的方式创建 issue_template目录

   如果是合并请求分支则需要创建 merge_request_templates，当合并分支时，可以使用此模板

3. 在 issue_template 目录下创建 模板文件

   比如 创建合并请求模板 CodeReview.md

   提交评审类型：
   - [ ] 新功能需求
   - [ ] Bug修复
   - [ ] 数据库更改 
   - [ ] 配置更新
   - [ ] 其它
   
   评审相关的需求号/Bug号：
   1
   2
   3
   4
   5
   6
   7
   8

   bug.md

   Bug 标题：
   
   状况描述：
   
   Assign：
   /assign
   
   Due Date：
   /due 
   
   Milestone：
   /milestone %
   
   Label：
   /label ~"Bug" 
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15

   feature.md

   Feature 标题：
   
   功能描述：
   
   Assign：
   /assign
   
   Due Date：
   /due 
   
   Milestone：
   /milestone %
   
   Label：
   /label 
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15

   merge.md

   一樣在 Project 的 default branch 建立 .gitlab/merge_request_templates/ 資料夾，接著以 Markdown 格式撰寫 Templates，例如下面的範例：

   相关 Issue： Closed #
   
   Assign：
   /assign
   
   Due Date：
   /due 
   
   Milestone：
   /milestone %
   
   Label：
   /label ~"Dev Leader" 
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UoSTvHr6-1650585952887)(D:\study\项目\GIt分支管理\gitlab使用.assets\image-20211020161117706.png)]

*写优秀的“需求” issue*
如果你要录入一个需求类的 issue，最好在内容主体中包含下面这些内容：

• 用一句话描述你的需求，并用它作为标题
• 这个需求是解决什么问题的？
• 这个需求对软件现有功能会造成什么影响？
• 这个需求应该实现什么样的功能？
• 这个需求是否依赖其他模块提供相关支持？
• [可选] 这个需求有哪些实现方式？
• [可选] 这些可选的实现方式分别有哪些优缺点？

*编写优秀的“bug” issue*
如果你要录入一个 bug issue，最好在内容主体中包含下面这些内容：

• 提供出现问题的软件版本号、操作系统环境等相关信息
• 提供能够稳定复现问题的相关步骤
• 描述期待行为与当前行为
• [可选] 你对这个 bug 原因的相关分析

怎样添加创建issue的模板

当你提交一个commit的时候在commit message里面使用#issue, 比如#8, gitlab 就会自动关联issue 8跟这个commit. 当然在gitlab

上面写comment的时候使用这个也是有效的.

那么如何跟随着commit关闭一个issue呢? 在confirm merge的时候可以使用一下命令来关闭相关issue:

fixes #xxx
fixed #xxx
fix #xxx
closes #xxx
close #xxx
closed #xxX

3.创建MileStones

这里的MileStones，和版本的概念差不多，可以把一个Issue划分在某个版本下。支持以版本的维度进行

项目管理。

基于Issue拉取分支以及发起Merge request

无论是GitHub还是GitLab，都可以方便地在Issue上创建分支。在该分支上解决了Issue的问题以后，提

交远程分支。就可以发起Merge request

merge完成后，该Issue的状态会自动变成closed

merge完成以后，分支状态就会变成merged，可删除该分支

对于大型项目， 每个 Issue 至少应该有两个 Label ，一个表示性质，另一个表示优先级。

todo→进行中→已完成→测试中→已测试

ToDo->开发中->代码审查中->合并master->部署测试环境->测试通过->已部署

表示优先级的 Label，可以采用下面的级别。

• 高优先级（High）：对系统有重大影响，只有解决它之后，才能去完成其他任务。
• 普通优先级（Medium）：对系统的某个部分有影响，用户的一部分操作会达不到预期效果。
• 低优先级（Low）：对系统的某个部分有影响，用户几乎感知不到。
• 微不足道（Trivial）：对系统的功能没有影响，通常是视觉效果不理想，比如字体和颜色不满意。