现在部门里对需求版本的项目管理都有一套较为成熟的体系了。但是对于bug的修复管理统计，还缺乏一套行之有效的方案。对于开发而言，修复bug在每日的工作中也占了一定的比重。而这部分的工作量目前没有很好的进行一个量化和统计。同时也没有一个很好的方式去展现目前已经发现的bug和已经修复的bug。使用Issue可以一定程度上解决上面所述的问题。本文章主要用于介绍在GitLab中如何创建和使用。同时如何为这个Issue创建分支和发起Merge Request。

如果大家经常使用Github上的开源项目，相信对Issue一定不陌生，在使用开源项目时，特别是一些比较新的项目，许多问题的解决方案都是在使用者提出的Issue里的，甚至是还没解决的。这时你就可以向开源项目的作者提Issue。让他注意到有这个问题，如果项目活跃，可能很快就会出新release修复你提的问题。

一般情况下，如果是一个团队内部使用的Issue，应该包含下面几项信息： 1.标题，描述。 2.分配给谁(Assignee)。 3.标签(Labels)。 4.对应的版本(Milestone)，可选。 5.预计完成时间(Due Date)，可选。

创建完Issue以后，可以在相关Issue下进行讨论和问题跟踪：

创建标签是为了给Issue和看板使用，一般来说，一个Issue应该有至少两种类型的Label，即Issue的类型和Issue的状态。其中Issue的状态可以用来构建看板的栏目。团队也可以根据自己团队的需要创建对应的Label。

在看板的页面，可以看到以Label为列汇总的Issue信息。团队也可以根据自己团队的需要创建对应的看板。

。

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

无论是GitHub还是GitLab，都可以方便地在Issue上创建分支。在该分支上解决了Issue的问题以后，提交远程分支。就可以发起Merge request