GitLab 工作流介绍（GitLab Flow）

迈不过友情╰ 2022-05-14 02:53 334阅读 0赞

GitLab 工作流提供了一种简单、透明和有效的 git 工作方式，并与问题跟踪系统相结合。

先上官方文档链接： [GitLab Flow][]

使用版本控制中常见的问题是，随着时间推移，产生越来越多的分支，在那些长期维护的分支中充斥着杂乱的修改内容。

## git 工作流的问题 ##

首先来看常见的 git 工作流：  
![这里写图片描述][70]

git 工作流主要的问题是：一、默认的 master 分支只是用于发布，开发都在其他分支上。二、对于多数应用来说过于复杂，特别是 release 和 hotfix 分支的不可部署导致使用上的复杂。

## GitHub 工作流的问题 ##

![这里写图片描述][70 1]

[GitHub 工作流][GitHub]十分简单，只有两个分支，master 和 feature。[Atlassian 公司推荐的工作流][Atlassian]也基本类似。

GitHub 工作流的主要问题是过于简单，没有对于常见的工作场景中的问题提出解决办法。

## GitLab 工作流中的生产分支（Production branch） ##

GitHub 工作流隐含一个假定：每次合并 feature，主分支的代码是立即发布的。然而，实际中常常不能满足这个假定，例如：你无法控制代码发布时间，例如 App 发布要等审核通过。再例如：发布时间窗口限制，合并分支的时候也许并不在发布时间窗口。

GitLab 推荐用生产分支来解决上述问题：

![这里写图片描述][70 2]

Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。

对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。

开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。

只有紧急情况，才允许跳过上游，直接合并到下游分支。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlbnJ5aHU3MTI_size_27_color_FFFFFF_t_70]

### 版本发布 ###

对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。

以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlbnJ5aHU3MTI_size_27_color_FFFFFF_t_70 1]

官方文档链接： [GitLab Flow][]

参考文章  
[http://www.ruanyifeng.com/blog/2015/12/git-workflow.html][http_www.ruanyifeng.com_blog_2015_12_git-workflow.html]

[GitLab Flow]: https://docs.gitlab.com/ee/workflow/gitlab_flow.html
[70]: /images/20220514/41d5b8ab59fd4818bbecb7a6923b83cf.png
[70 1]: /images/20220514/758bb534d57543aeba3cbe04beee6bdc.png
[GitHub]: https://guides.github.com/introduction/flow/index.html
[Atlassian]: https://www.atlassian.com/blog/archives/simple-git-workflow-simple
[70 2]: /images/20220514/5616e0751b6245fcbd959d31ff342797.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlbnJ5aHU3MTI_size_27_color_FFFFFF_t_70]: /images/20220514/39736ddd566742d8b3ab6264a85eb93c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlbnJ5aHU3MTI_size_27_color_FFFFFF_t_70 1]: /images/20220514/34b91d6579294423adcd2db19bd3458d.png
[http_www.ruanyifeng.com_blog_2015_12_git-workflow.html]: http://www.ruanyifeng.com/blog/2015/12/git-workflow.html