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/<username>/<projectname>/issues/<xxx>
预览：
cc/ @Mary @Jane @John
当你创建一个如上的带有描述的 MR，它将会：
- 当合并时，关闭包括工单
#xxx以及https://gitlab.com/<username>/<projectname>/issues/<xxx> - 展示一张图片
- 通过邮件提醒用户
@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 Pages 发布你的网站。
- 用它来发布你的网站 到
staging以及production环境。 - 用它来构建一个 iOS 应用。
- 用它来构建和发布你的 Docker 镜像到 GitLab 容器注册库。
我们已经准备一大堆 GitLab CI 样例工程作为您的指南。看看它们吧！
反馈：周期分析
当你遵循 GitLab 工作流进行工作，你的团队从点子到产品，在每一个过程的关键部分，你将会在下列时间获得一个 GitLab 周期分析的反馈：
- Issue： 从创建一个工单，到分配这个工单给一个里程碑或者添加工单到你的工单看板的时间。
- Plan： 从给工单分配一个里程碑或者把它添加到工单看板，到推送第一次提交的时间。
- Code： 从第一次提交到提出该合并请求的时间。
- Test： CI 为了相关合并请求而运行整个过程的时间。
- Review： 从创建一个合并请求到合并它的时间。
- Staging： 从合并到发布成为产品的时间。
- Production（Total）： 从创建工单到把代码发布成产品的时间。
