gitlab mr wip 怎么弄成_基于GitLab的工作流程设计

GitLab 是一个基于 git 的仓库管理程序，也是一个方便软件开发的强大完整应用。

GitLab 拥有一个“用户新人友好”的界面，通过图形界面和命令行界面，使你的工作更加具有效率。GitLab 不仅仅对开发者是一个有用的工具，它甚至可以被集成到你的整个团队中，使得每一个人获得一个独自唯一的平台。

GitLab 工作流逻辑符合使用者思维，使得整个平台变得更加易用。相信我，使用一次，你就离不开它了！

GitLab 工作流

GitLab 工作流是在软件开发过程中，在使用 GitLab 作为代码托管平台时，可以采取的动作的一个逻辑序列。

GitLab 工作流遵循了提升团队的工作效率以及凝聚力。这种提升，从引入一个新的项目开始，一直到发布这个项目，成为一个产品都有所体现。这就是我们所说的“如何通过最快的速度把一个点子在 10 步之内变成一个产品”。

软件开发阶段

一般情况下，软件开发经过 10 个主要阶段；GitLab 为这 10 个阶段依次提供了解决方案：IDEA： 每一个从点子开始的项目，通常来源于一次闲聊。在这个阶段，GitLab 集成了Mattermost。

ISSUE： 最有效的讨论一个点子的方法，就是为这个点子建立一个工单讨论。你的团队和你的合作伙伴可以在工单追踪器issue tracker中帮助你去提升这个点子

PLAN： 一旦讨论得到一致的同意，就是开始编码的时候了。但是等等！首先，我们需要优先考虑组织我们的工作流。对于此，我们可以使用工单看板Issue Board。

CODE： 现在，当一切准备就绪，我们可以开始写代码了。

COMMIT： 当我们为我们的初步成果欢呼的时候，我们就可以在版本控制下，提交代码到功能分支了。

TEST： 通过GitLab CI，我们可以运行脚本来构建和测试我们的应用。

REVIEW： 一旦脚本成功运行，我们测试和构建成功，我们就可以进行代码复审code review以及批准。

STAGING：： 现在是时候将我们的代码部署到演示环境来检查一下，看看是否一切就像我们预估的那样顺畅——或者我们可能仍然需要修改。

PRODUCTION： 当一切都如预期，就是部署到生产环境的时候了！

FEEDBACK： 现在是时候返回去看我们项目中需要提升的部分了。我们使用周期分析 Cycle Analytics来对当前项目中关键的部分进行的反馈。

简单浏览这些步骤，我们可以发现，提供强大的工具来支持这些步骤是十分重要的。在接下来的部分，我们为 GitLab 的可用工具提供一个简单的概览。

GitLab flow

GitLab flow是GitLab官方推荐的分支管理策略，Gitlab flow 的最大原则叫做"上游优先"(upsteam first)，即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。

持续发布

持续发布适用于web等可以无缝更新的项目。

分支约定

临时分支：在开发完成会被删除功能分支 feature - 用于新功能的开发，建议以issue-feature-name命名

修复分支fix - 用户bug的修复，建议以issue-fix-name命名

固定分支开发分支 master - 用于发布到测试环境，上游分支为 feature 和 fix，该分支为受保护分支

预发分支 pre-production - 用于发布到预发环境，上游分支为 master

正式分支 production - 用于发布到正式环境，上游分支为 pre-production

使用流程克隆项目到本地

git clone git@example.com:project-name.git检出分支

git checkout -b $issue-feature-name提交并push到GitLab仓库

git commit -am "My feature is ready"

git push origin $issue-feature-name运行GitLab CI

在GitLab上创建一个Merge Request

项目管理者进行代码审查，合并到master

运行第二次GitLab CI

进行产品测试

将master分支合并到pre-production

运行第三次GitLab CI

进行产品测试

将pre-production分支合并到prouction，并且为prouction打上tag，保持prouction与线上代码一致

版本发布

版本发布适用于APP、小程序等有版本规划的项目。

分支约定

临时分支：在开发完成会被删除功能分支 feature - 用于新功能的开发，建议以issue-feature-name命名

修复分支fix - 用户bug的修复，建议以issue-fix-name命名

固定分支开发分支 master - 用于发布到测试环境，上游分支为 feature 和 fix，该分支为受保护分支

发布分支 stable - 用于发布到预发环境，上游分支为 master，建议以version-stable命名，该分支要尽可能晚的创建，每次更新此分支都要更新一个小版本号

使用流程克隆项目到本地

git clone git@example.com:project-name.git检出分支

git checkout -b $issue-feature-name提交并push到GitLab仓库

git commit -am "My feature is ready"

git push origin $issue-feature-name运行GitLab CI

在GitLab上创建一个Merge Request

项目管理者进行代码审查，合并到master

运行第二次GitLab CI

进行产品测试

将master分支合并到stable，如果是新版本则创建一个新的stable分支

为stable打上tag，并进行发布

Merge Request 合并请求

功能分支和修复分支合并进master分支，必须通过 Merge Request。

master分支应该受到保护，不是每个人都可以修改这个分支，以及拥有审批 Merge Request 的权力。

每一次 MR 都会有一个标题(这个标题总结了这次的改动)并且一个用 Markdown 书写的描述。在描述中，你可以简单的描述该 MR 做了什么，提及任何工单以及 MR(在它们之间创建联系)，并且，你也可以添加个关闭工单模式，当该 MR 被合并的时候，相关联的工单就会被关闭。

例如:

## 增加一个新页面

这个 MR 将会为这个项目创建一个包含该 app 概览的 `readme.md`。

Closes #xxx and https://gitlab.com///issues/

预览：


cc/ @Mary @Jane @John

当你创建一个如上的带有描述的 MR，它将会：当合并时，关闭包括工单 #xxx 以及 https://gitlab.com///issues/

展示一张图片

通过邮件提醒用户 @Mary、@Jane，以及给 @John

你可以分配这个 MR 给你自己，直到你完成你的工作，然后把它分配给其他人来做一次代码复审。如果有必要的话，这个 MR 可以被重新分配多次，直到你覆盖你所需要的所有复审。

开发完成后，在提交说明里面，可以写上"closes #67"。，只要commit message里面有下面这些动词 + 编号，就会关闭对应的issue。

注： 添加关闭工单样式到你的 MR 以便可以使用 GitLab 周期分析追踪你的项目进展，是十分重要的。它将会追踪“CODE”阶段，衡量第一次提交及创建一个相关的合并请求所间隔的时间。

WIP MR

WIP MR 含义是 在工作过程中的合并请求，是一个我们在 GitLab 中避免 MR 在准备就绪前被合并的技术。只需要添加 WIP: 在 MR 的标题开头，它将不会被合并，除非你把 WIP:删除。

当你改动已经准备好被合并，编辑工单来手动删除 WIP: ，或者使用就像如下 MR 描述下方的快捷方式。

WIP 模式可以通过斜线命令 /wip 快速添加到合并请求中。只需要在评论或者 MR 描述中输入它并提交即可。

Code Review 代码审核

旦你创建一个合并请求，就是你开始从你的团队以及合作方收取反馈的时候了。使用图形界面中的差异比较功能，你可以简单的添加行内注释，以及回复或者解决它们。

你也可以通过点击行号获取每一行代码的链接。

在图形界面中可以看到提交历史，通过提交历史，你可以追踪文件的每一次改变。你可以以行内差异或左右对比的方式浏览它们。

如果你遇到合并冲突，可以快速地通过图形界面来解决，或者依据你的需要修改文件来修复冲突。

Issue 工单

GitLab 有一个强大的工单追溯系统，在使用过程中，允许你和你的团队，以及你的合作者分享和讨论建议。所有的开发工作都应该以工单任务为导向。

工单是 GitLab 工作流的第一个重要重要特性。以工单的讨论为开始； 跟踪新点子的改变是一个最好的方式。

这十分有利于：讨论点子

提交功能建议

提问题

提交错误和故障

获取支持

精细化新代码的引入

每一个在 GitLab 上部署的项目都有一个工单追踪器。找到你的项目中的 Issues > New issue 来创建一个新的工单。建立一个标题来总结要被讨论的主题，并且使用 Markdown 来形容它。看看下面的“专业技巧”来加强你的工单描述。

GitLab 工单追踪器提供了一个额外的实用功能，使得步骤变得更佳易于管理和考虑。下面的部分仔细描述了它。

截止日期

每一个工单允许你填写一个截止日期。有些团队工作时间表安排紧凑，以某种方式去设置一个截止日期来解决问题，是有必要的。这些都可以通过截止日期这一功能实现。

当你对一个多任务项目有截止日期的时候——比如说，一个新的发布活动、项目的启动，或者按阶段追踪任务——你可以使用里程碑。

受托者 Assignee

要让某人处理某个工单，可以将其分配给他。你可以任意修改被分配者，直到满足你的需求。这个功能的想法是，一个受托者本身对这个工单负责，直到其将这个工单重新赋予其他人。

这也可以用于按受托者筛选工单。

标签 Lable

GitLab 标签也是 GitLab 流的一个重要组成部分。你可以使用它们来分类你的工单，在工作流中定位，以及通过优先级标签来安装优先级组织它们。

标签使得你与工单看板协同工作，加快工程进度以及组织你的工作流。

常用 Label

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

表示性质的 Label，可以参考这篇文章的范例。

表示优先级的 Label，可以采用下面的级别。高优先级(High)：对系统有重大影响，只有解决它之后，才能去完成其他任务。

普通优先级(Medium)：对系统的某个部分有影响，用户的一部分操作会达不到预期效果。

低优先级(Low)：对系统的某个部分有影响，用户几乎感知不到。

微不足道(Trivial)：对系统的功能没有影响，通常是视觉效果不理想，比如字体和颜色不满意。

看板 Board

在项目中，GitLab 工单看板是一个用于计划以及组织你的工单，使之符合你的项目工作流的工具。

看板包含了与其相关的相应标签，每一个列表包含了相关的被标记的工单，并且以卡片的形式展示出来。

这些卡片可以在列表之间移动，被移动的卡片，其标签将会依据你移动的位置相应更新到列表上。

里程碑 Milestones

里程碑 是 GitLab 中基于共同的目标、详细的日期追踪你队伍工作的最好工具。

不同情况下的目的是不同的，但是大致是相同的：你有为了达到特定的目标的工单的集合以及正在编码的合并请求。

这个目标基本上可以是任何东西——用来结合团队的工作，在一个截止日期前完成一些事情。例如，发布一个新的版本，启动一个新的产品，在某个日期前完成，或者按季度收尾一些项目。

构建、测试以及发布

GitLab CI

GitLab CI 是一个强大的内建工具，其作用是持续集成、持续发布以及持续分发，它可以按照你希望的运行一些脚本。它的可能性是无止尽的：你可以把它看做是自己运行的命令行。

它完全是通过一个名为 .gitlab-ci.yml 的 YAML 文件设置的，其放置在你的项目仓库中。使用 Web 界面简单的添加一个文件，命名为 .gitlab-ci.yml 来触发一个下拉菜单，为不同的应用选择各种 CI 模版。

使用案例

GitLab CI 的使用案例：

我们已经准备一大堆 GitLab CI 样例工程作为您的指南。看看它们吧！

反馈：周期分析

当你遵循 GitLab 工作流进行工作，你的团队从点子到产品，在每一个过程的关键部分，你将会在下列时间获得一个 GitLab 周期分析的反馈：Issue： 从创建一个工单，到分配这个工单给一个里程碑或者添加工单到你的工单看板的时间。

Plan： 从给工单分配一个里程碑或者把它添加到工单看板，到推送第一次提交的时间。

Code： 从第一次提交到提出该合并请求的时间。

Test： CI 为了相关合并请求而运行整个过程的时间。

Review： 从创建一个合并请求到合并它的时间。

Staging： 从合并到发布成为产品的时间。

Production(Total)： 从创建工单到把代码发布成产品的时间。

参考资料