GitLab 与 GitHub对比（2022版）

版本控制系统 (VCS) 一直走在 Dev*Ops 革命的前沿，而 Git 则是这场革命的领军者。从 2005 年创建以来，Git 迅速崛起，成为全球范围内采用最为广泛的版本控制系统之一。

尽管现在 Git 的应用很多，但两种托管解决方案已经在开发者和企业中广受欢迎——也就是 GitHub 和 GitLab。

GitLab

2014 年，GitLab 在 MIT 许可下成立并发布。随着时间的推移，该产品在产品模型和理念上都有所发展，最终形成了一个平台，该平台旨在满足从软件开发生命周期 (SDLC) 到项目管理的端到端 DevOps 团队的需求。对于那些没有内部 DevOps 专家且没有免费周期的团队来说，平台方法尤其有益，因为他们可以评估开放市场上的各种可用工具，而不是想要一个“正常工作”的解决方案。GitLab 理念的隐藏成本在于失去了选择和组合临时工具的自由——这本身就是 GitHub 的隐藏成本。GitLab 最近宣布了通过 IPO 上市的计划——TechCrunch 对此次发布进行了精彩的报道。

GitLab 估计 2020 年有超过 3100 万的开发人员，在自我管理的 Git 市场中占有 ⅔ 的份额。biterg.io 还提供了一个充满有趣的实时统计数据的仪表板。

GitLab 的著名项目和客户包括 Goldman Sachs、Ticketmaster、云原生计算基金会 (CNCF) 等。

相关文章：什么是 GitLab？

GitHub

GitHub 是第一个云托管的 Git 解决方案，于 2008 年推出并为此类解决方案设定了标准；一个显著的例外是成立于 1999 年的 SourceForge。随着 GitHub 等以云为中心的服务越来越受欢迎，越来越多的企业开始采用这种模式，并寻求 GitHub 等领导者的支持。2018 年，微软收购了 GitHub，这既是一项战术行动（微软在许多代码基础上依赖 GitHub 服务），也是一项战略行动（这是微软更加重视云解决方案的一部分）。GitHub 平台采用更加自我管理的方法，支持广泛的社区开发解决方案，以提供 DevOps 生命周期。

GitHub 拥有 5600 万开发人员，在 2020 年完成了 19 亿次更新，并在当年创建了 6000 万个新仓库。

GitLab 的著名项目和客户包括 Procter & Gamble、Hashicorp、Autodesk、DataDog、Spotify 等。

GitLab 与 GitHub – 比较

由于这两家供应商都提供 Git 解决方案，所以它们有很多共同之处也就不足为奇了，事实上，对于一些只需要基本版本控制系统之外的特定功能子集的组织来说，它们可能别无二致。除了它们固有的相似之处外，GitLab 和 GitHub 经常发布与对方平台的功能相竞争的功能，导致它们在所支持的功能上不断合并和分歧。

除了核心 Git 服务之外，GitLab 和 GitHub 对为客户提供价值的最佳方式有着不同的看法：

• GitLab 致力于提供一个完整的服务平台，以增强 Git 的本机功能并满足客户的端到端需求，例如，Google 搜索“GitLab ci/cd 示例”会返回包括此页面在内的多个结果。
• GitHub 主要直接关注 Git 活动，几乎没有集成工具，而是一个充满活力的第三方应用程序用户生态系统； 谷歌搜索 “github ci/cd examples” 也会返回 GitLab 结果，但在结果的第一页没有提到 GitHub。

工作流

对于一些首次采用 Git 的组织来说，如果没有支持的托管服务（如 GitHub 或 GitLab），那么工作流可能会是一个重大挑战。尽管有许多不同的方式可以来实现 Git Flow，但来自 nvie.com 的这张图表展示了一种常见的方法：

GitLab 和 GitHub 都旨在通过各自的流程简化此模型：

• GitLab Flow 提供了几个不同的示例场景，从生产分支到更通用的每个环境分支，再到以发布为中心的方法。其中每个场景都设计用于解决遇到的各种业务需求和 DevOps 成熟度问题。
• GitHub Flow 建议采用功能驱动的分支方法，将所有更改合并到一个主分支中，然后进行部署。这个工作流比最初的 Git 流程简化了很多，它依赖于始终能够从单个分支执行部署的业务——这是软件即服务 (SaaS) 项目中的常见模式——这可能不适合所有业务需求。

尽管 GitLab 和 GitHub 可能规定了一些不同的流程管理方法，因为这两种产品都实现了基于 Git 的解决方案，但任何策略都可以根据团队或企业的需要轻松移植到这两个平台上。

自托管

尽管这两种解决方案过去和现在都主要是软件即服务 (SaaS)，但出于监管、安全或工作流的原因，一些组织可能需要自托管 Git。GitLab 和 GitHub 都提供此功能，其中后者需要一个企业组织帐户，而且需要付费。

私有仓库

共享数据是 Git 的核心目标之一，但是与世界共享数据可能并不符合每个组织的目标，因此 GitLab 和 GitHub 都支持私有仓库，例如通过仅限邀请方式。在这两种情况下，私有仓库的数量是不受限制的，但是却限制免费允许的 collaborator 数量，并根据此后的付费级别提高限制。

持续集成和持续部署

GitLab 和 GitHub 都认识到 CI/CD 与 SDLC 和 DevOps 文化相关的重要性和价值，但是，对于如何最好地支持这些努力，它们各自采取了不同的方法。GitLab 的平台概念包括许多工具选项，比如管道和运行器。GitHub 包含类似于 GitLab 运行器的操作，但是其他操作（如持续部署）则由第三方和社区项目来支持。

文档和 Wiki

GitLab 和 GitHub 都认识到文档和通信作为健康的 DevOps 组织的基础能力的重要性。虽然内联文档（如Git Readme 文件）是本机提供的，但只有 GitLab 免费提供 wiki 支持。

问题跟踪

DevOps 文化所固有的是积极管理、报告和参与变更生命周期的能力；其中一个重要的变化类别是“问题”。在 GitLab / GitHub 世界中，问题并不是特定的缺陷，而是可以代表有关与仓库相关的软件项目的各种讨论方式。讨论的范围可以从缺陷到功能请求，再到版本发布，再到帮助论坛的形式。重要的是，问题可以与特定的分支相关联，甚至可以与相关存储库中的代码行相关联，从而实现高度针对性的关注以及对项目未来计划的清晰洞察。

安全断言标记语言 (SAML) 单点登录 (SSO)

一些项目（例如 Linux 内核）是公开的，任何开发人员都可以提交贡献以供考虑； 在这种情况下，开发人员需要由 Linux 内核的提供商 GitHub 进行身份验证。一些组织对需要外部工作流的身份验证和授权有更加严格的要求，例如与企业身份产品或集中式身份验证网关集成。GitLab 包括 SSO 集成，但是 GitHub 需要企业组织（GitHub 的最高付费服务层级术语）

价值流管理

价值流管理 (VSM) 是上一篇文章中讨论的一种重要的新兴精益业务实践。虽然 GitHub 生态系统确实有实施 VSM 的项目和工具，但 GitLab 已将实践作为价值流分析直接集成到他们的平台中。

安全与合规工具

如上文所述，GitLab 和 GitHub 提供了强大的安全框架和合规性文档。下表中比较了该域在两个平台上的不同功能。

GitLab 与 GitHub – 比较表

* 虽然包含私有仓库，但是 collaborator 的数量因定价和提供商而异。

替代方案

尽管 GitLab 和 GitHub 占据了 Git 市场的重要部分，但还是有几种可用的替代方案：

Bitbucket（链接）

作为 Atlassian 产品套件的一部分，Bitbucket 与 GitLab 和 GitHub 共享许多功能，包括自托管选项。得益于 Atlassian 生态系统，Bitbucket 能够利用来自 Jira、Bamboo、Opsgenie、Statuspage 等的功能来支持整个 DevOps 生命周期。

SourceForge（链接）

SourceForge Git 服务支持 Git 的全部功能以及 Webhook，以便在 Git 事件的两侧集成临时服务。在其 About 页面上，SourceForge 报告称“使用我们提供的工具，SourceForge 上的开发人员在超过 502000 个项目中创建了强大的软件；我们拥有数百万注册用户。我们的热门目录将每月近 3000 万用户与所有这些开源项目联系起来，每天提供超过 260 万次下载。我们的商业软件目录列出了超过 72400 个软件名称。”

Cloud (GCP Cloud Source Repositories / AWS CodeCommit / Azure Repos)

公共云解决方案支持 Git 操作，但这些产品的价值主要来自其提供商的全球规模和弹性，以及与相应云生态系统中其他服务的紧密集成。例如，自动启动云资源以响应代码更改的能力可以为组织提供重要价值。

Gogs（链接）

Gogs 是一个用 Golang 编写的开源 Git 服务器，旨在以一种简单而稳定的方式自托管 Git 服务（具有讽刺意味的是，该项目托管在 GitHub 上）。除了常见的 Git 功能外，Gogs 还支持组织网络钩子，包括 Slack、Discord 和 DingTalk。

结论

说到底，还有一个大问题，那就是 GitLab 和 GitHub，我应该选择哪一个？考虑以下一些标准可能会有助于回答这个问题：

能力

因为 GitLab 和 GitHub 都实现了 Git 服务器，所以如果 Git 是您团队或组织的正确解决方案，那么任何一家供应商都有望成为合适的选择。虽然核心 Git 功能由每个供应商的图形界面包装，但作为开发环境的 Visual Studio Code 的兴起增加了开发人员体验讨论的复杂性——例如，代码审查应该在 Git 网页界面中进行还是直接在 IDE 中进行。

成本

作为云服务，GitLab 和 GitHub 结构的使用成本都高于帐户订阅成本，这将是两者之间成本差异的主要驱动因素。例如，当考虑作为 CI/CD 管道一部分的 Runner 或 Action 的成本时，GitLab 和 GitHub 分别包含每月 400 / 10000 / 50000 和 2000 / 3000 / 50000 分钟的计划。虽然超支会产生额外成本，但自动化的小增量成本可能会抵消下一层服务的额外成本；这必须由团队单独计算并仔细建模。不受这些数字影响的是自托管资源，它们对两个提供商都是免费的，但包括它们自己的固有成本。

功能

虽然功能很可能是选择托管 Git 解决方案的决定性因素，但 GitLab 和 GitHub 之间正在进行的军备竞赛确保了对供应商的功能比较充其量只是一个暂时的观点。一些团队发现匹配其业务需求的功能示例包括：

• 分析
• 问题跟踪
• 协作
• 自托管

理念

对于一些团队来说，GitLab 平台方法可以是一个重要的性能推手，因为它对工具和方法有自己的见解，同时提供这些见解的包含实现。对于其他团队，GitHub 社区方法（依靠贡献的工具和服务来支持各种功能）可以通过确保组织能够满足从安全性到工具集成再到流程标准等所有要求，从而帮助提高性能。一个组织很可能只适合其中一个类别，这使其成为选择供应商的关键区别。