gitlab合并分支_从浅到深讲讲为什么要用gitlab

最近项目管理上遇到点难题，版本多了，开发人员多了，单纯的git管理还是很多问题，一方面是开发人员权限过大，二是运维人员不太了解我们开发上面的流程，于是想着用更好的工具来管理项目。于是想到gitlab。

愿景

GitLab reimagines the scope of DevOps tooling to include developers, operations, and security teams in one single application. This dramatically reduces friction, increases collaboration, and drives a competitive advantage. Doing away with context switching and having all of the necessary information in one place closes the loop and enables a better understanding of each team's needs.

GitLab认为DevOps开发工具的范围应当在一个应用中包括开发者、运维人员和安全团队。这样能显著减少挫折感，增加合作，启动一个有竞争力的优势。带着上下文转换Doing Aways并且在一个地方就有必要的信息，能够闭环，并且使得团队之间相互更好的理解成为可能

目标：200%更快的DevOps生命周期

从项目计划和源代码管理到CI/CD和监控，GitLab是整个DevOps生命周期的单一应用。只有GitLab允许并行的DevOpes，使得软件生命周期200%更快。

這里的CI/CD其实指的是持续集成（CI）和持续交付（CD），CI就是软件工程师每天频繁地将更新代码的副本传递到共享位置的过程。所有的开发工作都在预定的时间或事件中进行集成，然后自动测试和构建工作。通过CI，开发过程中出现的错误能被及时发现，这样不仅加速了整个开发周期，而且使软件工程师的工作效率更高。而CD 表示持续交付（CD）是创建高质量应用程序的第二个难题。CD是一门软件开发学科，利用技术和工具快速地交付生产阶段的代码。由于大部分交付周期都是自动化的，所以这些交付能够快速地完成。这方面的知识可以参参考https://blog.csdn.net/rancherlabs/article/details/80133523 ，這也是一门大学课

GitLab 工作流介绍

其实gitlab的核心还是提供了一种简单、透明和有效的 git 工作方式，并与问题跟踪系统相结合。這就是GitLab 工作流介绍（GitLab Flow）

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

• git 工作流的问题

首先来看常见的 git 工作流：

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

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

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

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

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

协作

在一个 GitLab 项目上一起工作的最简单方法就是赋予协作者对 git 版本库的直接 push 权限。 你可以通过项目设定的 “Members（成员）” 部分向一个项目添加写作者，并且将这个新的协作者与一个访问级别关联（不同的访问级别在 组 中已简单讨论）。 通过赋予一个协作者 “Developer（开发者）” 或者更高的访问级别，这个用户就可以毫无约束地直接向版本库或者向分支进行提交。

另外一个让合作更解耦的方法就是使用合并请求。 它的优点在于让任何能够看到这个项目的协作者在被管控的情况下对这个项目作出贡献。 可以直接访问的协作者能够简单的创建一个分支，向这个分支进行提交，也可以开启一个向 master 或者其他任何一个分支的合并请求。 对版本库没有推送权限的协作者则可以 “fork” 这个版本库（即创建属于自己的这个库的副本），向 那个 副本进行提交，然后从那个副本开启一个到主项目的合并请求。 这个模型使得项目拥有者完全控制着向版本库的提交，以及什么时候允许加入陌生协作者的贡献。（这有点类似 github，但目前github私有库收费）

在 GitLab 中合并请求和问题是一个长久讨论的主要部分。 每一个合并请求都允许在提出改变的行进行讨论（它支持一个轻量级的代码审查），也允许对一个总体性话题进行讨论。 两者都可以被分配给用户，或者组织到 milestones（里程碑） 界面。

这个部分主要聚焦于在 GitLab 中与 Git 相关的特性，但是 GitLab 作为一个成熟的系统，它提供了许多其他产品来帮助你协同工作，例如项目 wiki 与系统维护工具。 GitLab 的一个优点在于，服务器设置和运行以后，你将很少需要调整配置文件或通过 SSH 连接服务器；绝大多数的管理和日常使用都可以在浏览器界面中完成。

gitlab虽然暂时在理解上，但对于当前项目的管理来说已经有很大的提升了，后继使用一段时间再来写写使用的心得，今天先這样。