版本控制系统 (VCS)——也被称为源代码管理器 (SCM) 或修订控制系统 (RCS)——的重要性日益增加，不仅仅是对编制软件的企业而言，对其他企业也是如此。Future Market Insights 的报告表明，2021 年，VCS 市场的总需求预计将达到约 6.3 亿美元，一直到 2031 年，将以每年近 11% 的速度增长。关键技术组成的进步（例如自动化）以及其他应用（例如云基础设施）不断扩大的可集成范围共同推动着需求的增长。
长期以来，体现 VCS 价值的一个方面就是，使用该系统进行管理能够节省成本并提高效率，尤其是对于大型软件团队而言。相关功能包括实时跟踪、合并操作分析以及集成回滚选项。除了能确保团队对 VCS 监控的软件更有信心外，这些关键功能也是整个行业通过不同的独立团队共同为大型项目做出贡献的关键推动因素——这也是 DevOps 文化的一个重要方面。
版本控制系统
版本控制系统一般分为两类，但某些解决方案为实现两类系统的混合模式会抛开二者的差异：
- 集中式 – 服务器作为仓库会随着时间的推移跟踪客户生成的所有变化和版本
- 分布式 – 仓库仍然会跟踪所有变化和版本，但每个开发人员都会保留一份本地记录，通常还会有一份作为数据源保存的远程拷贝
分布式版本控制系统 (DVCS) 变得十分受欢迎，主要原因是，随着 DevOps 文化的发展，人们开始认识到开发者独立性的价值。DVCS 允许开发者在一段时间内进行本地开发或在团队之外开展工作，对 DevOps 组织而言，这或许是成败攸关的能力。
让我们回顾一下目前几种重要的 VCS 方案：
并行版本系统 (CVS) 版本控制
CVS 是最早的 VCS 之一，发布于 1986 年（发布时间只晚于 IBM OS/360 SCCS），使用客户端/服务器的模式实现开发者互动。CVS 使用无保留签出策略，在不造成冲突的前提下支持对一个文件进行多个并发改动。
虽然已不再普遍使用，但 CVS 建立的一些概念和策略为现代 VCS 奠定了基础。
由GPL 提供许可
Git
Git 作为分布式 VCS 为开发者提供了完整的仓库克隆能力——除了以透明的方式支持备份和恢复结构外，从小型项目到 Linux 内核等大型项目，Git 为广泛的开发工作流程提供支持。同时，分布式特点使得 Git 中的操作几乎完全能在本地系统上进行，这样完成每个操作就比等待远程服务器响应要快得多。主动开发过程中，Git 会将更改的部分分离出来并处理成满足合并条件的代码分支。
Git 几乎已成为 DevOps 文化的代名词（人们甚至创造了一个新的术语——“GitOps”）并在 VCS 领域扮演着重要角色。尽管可以选择自我托管，Git 通常情况下仍然是以 SaaS 的形式实现，包括直接途径（如 GitHub 和 GitLab）以及白标服务（如 BitBucket）等实现方案。许多组织发现，这种模式有助于降低首次实现 VCS 的门槛，也有助于从其他产品完成过渡。
由 GPL v2（以及其他许可证）提供许可
Apache Subversion (SVN)
https://subversion.apache.org/
Subversion 坚持采用专门的客户/服务器模式，为变更管理提供集中式架构。目录和文件等作为第一类对象，允许创建、修改、复制、删除和重命名等操作。“提交”彻底原子化，变更成本与其大小成正比（即复杂性），而非原始数据量，这就降低了分支管理的成本。
尽管客户端/服务器模式会增加总体拥有成本 (TOC)——包括运行服务器的基础设施和支持人员的成本——但 Subversion 用于变更管理的方法针对特定的用途却极其奏效，即存在大量代码的情况，尤其是针对二进制文件。内部算法支持将二进制文件理解为文本，从而有效理解随时间变化的变化，并在变化中执行更有效的操作；这同样也减少了随着时间推移而逐渐增加的分支数量。Subversion 会在本地保留可执行标志，为大型二进制代码库提供一定的便利性。
由 Apache 2.0 提供许可
Mercurial
https://www.mercurial-scm.org/
Mercurial 是分布式版本控制系统，支持保存仓库到本地，然后再将变更合并到集中化版本。Mercurial 的命令语法设计非常简单，便于用户快速理解。随着时间推移，在名为修订日志 (RevlogNG) 的数据结构中，线性跟踪各种变更情况。
修订日志结构允许 Mercurial 用户在任意时间点与仓库内容交互。这种变更跟踪的方法对于文件数量和贡献者数量众多的项目尤其有效。这在选择 Mercurial 作为 VCS 的项目中均有体现，比如 Mozilla 和 NGINX。
由 GPL v2+ 提供许可
相关文章：Mercurial 与 Git 对比
Bazaar
https://bazaar.canonical.com/en/
Bazaar 聚焦于开发者体验，通过借鉴其他 VCS（如 Git 和 SVN）的功能，实现了一种结合分布式和集中式策略的混合模式。在这种混合模式的支持下，开发者可以使用远程共享仓库提高存储效率，也可以选择将内容拉取到本地系统中，这些功能都被细化的权限模型封装到一起。
Bazaar 的功能特性和理念使它成为众多项目的选择对象，尤其是已经在 Canonical 生态系统中开展工作的组织——比如使用 Ubuntu 操作系统的组织——在与同类产品比较时，可能会认为 Bazaar 更有吸引力。虽然有着 Canonical 支持，但 Bazaar 完全是跨平台的工具，而它存在的目的就是为了在源代码管理方面让人产生一种“它就是管用”的想法。
由 GPL v2+ 提供许可
版本控制解决方案
我们已经熟悉了一些顶级的 VCS 技术，现在让我们来了解一下应用这些技术的产品：
GitLab
源代码控制方案：Git
GitLab 专注于 DevOps 工作的生命周期，提供相应的工具，在 DevOps 各阶段为开发者提升可视化及优化各种能力。底层 Git 仓库托管以及分支和发布管理等相关功能。
GitLab 在与它最大的竞争对手 GitHub 的长期博弈中创新开发了各种特性和功能，而这些特性和功能如今已被视作 Git 供应商应提供的标准化内容。从安全代码扫描到自动化和文档，GitLab 团队在将近十年的时间里一直保持着先发优势。即使是选择了不同供应商的团队，关注 GitLab 的近况往往也能帮助他们洞察行业走势。
GitLab Self-Managed 使得团队能够彻底控制实施过程，同时保留云特性和功能。
GitLab 按 CI/CD 时间配额（分钟）提供免费和付费服务，以及针对小规模业务和小型企业的订阅服务：https://about.gitlab.com/pricing/
相关文章：什么是 GitLab？
GitHub
源代码控制方案：Git
GitHub 于 2018 年被微软收购，它也是开源项目领域的主要工具，在 2020 年拥有超过 4000 万用户。在支持提供 Git 仓库核心功能的同时，GitHub 还有着许多管理软件开发周期的工具，自动化就是其中一项功能。
GitHub 对开发者而言已是耳熟能详的名字，它的章鱼猫吉祥物几乎就是 Git 的代表性标志——没有 GitHub 的 VCS 工具清单是不完整的。GitHub 的生态系统包含了各种工具，从管理漏洞和更新（如 Dependabot）到供应链可靠性的提交签名，再到变更控制（如对拉取请求的必要审核），以强化对标准的遵循。
虽然 GitHub 的托管产品最为常见，但 GitHub 企业版也允许有本地部署需求的组织实现自行托管。
GitHub 提供三层付费订阅，并相应配备了一系列能力：https://github.com/pricing
BitBucket Cloud
源代码控制方案：Git、Mercurial
BitBucket 将常见的 Git 结构引入 Atlassian 生态系统，并与 Jira 等其他工具集成，实现项目管理和可视化。BitBucket Pipelines 和 BitBucket Deployments 支持自动化无服务器 CI/CD 活动，同时支持包括 Jira 和 Slack 在内的各种更新渠道。
尽管 BitBucket 的核心 Git 功能与 GitLab 和 GitHub 有着大量重叠部分，但它与丰富的 Atlassian 生态系统紧密集成的特性值得追求敏捷、看板或其他类似策略的团队持续关注。从 Confluence 设计文档的构想到 Jira 故事的实施，再到 Statuspage 的监控和警报，BitBucket 作为软件开发的十字路口，负责全面跟踪代码开发和部署的整个生命周期。
BitBucket Server（以前叫 Stash）可以经过授权支持内部托管的 Git 仓库功能和用户熟悉的网络界面。
BitBucket 根据用户数量、存储容量和构建时间（分钟）定价，共有三个级别：https://www.atlassian.com/software/bitbucket/pricing
SourceForge
源代码控制方案： Git、Subversion、Mercurial（链接）
Sourceforge 不仅实现了以软件即服务 (SaaS)模式托管 VCS 软件库的理念，该网站还通过 Apache Allura 为多个 VCS 后端提供支持，并将仓库集成到主要由开源开发者组成的社区中，进而拓展了这一理念。除了传统的仓库，Sourceforge 还包括 wikis 站点、数据库、支持论坛、评论以及其他以社区为主的功能，目的是为了在软件项目方面促成更多合作。
Sourceforge 模式是迭代仓库托管基础模式的重要范例。使用其他托管工具（比如 GitHub 和 GitLab）的项目自然会有社区，但社区优先的源代码管理理念开启了一个独特且有价值的视角，尤其是对于管理大型软件项目的组织而言。
Sourceforge 主要根据社区功能定价，如推广、评论、白皮书和洞察等，有着不同的定价等级：https://sourceforge.net/software/vendors/pricing/
云 VCS 解决方案
https://azure.microsoft.com/en-us/services/devops/repos/
https://aws.amazon.com/codecommit/
https://cloud.google.com/source-repositories
源代码控制方案：Git
以上三大公有云供应商均支持在其各自的云产品中托管 Git 仓库。从机制层面来看，这些解决方案与 GitHub 和 GitLab 的产品非常相似，包括权限管理、分支策略、变更历史等等。
但它们与 GitHub 和 GitLab 是否就是相同东西？答案为：不完全是。尽管一些云服务与外部供应商的仓库功能存在着密切联系，但在云解决方案中，服务与仓库的深度整合则充分证明它们考虑到了采用云优先策略的组织有着怎样的需求。除了提供以服务为中心的方案外，附加的身份与访问管理 (IAM) 集成有效增强了传统的托管 VCS 模式。
定价通常与存储和/或用户数量挂钩，但供应商通过进一步的云定价洽谈可能会获得一定优惠：
https://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/
https://aws.amazon.com/codecommit/pricing/
https://cloud.google.com/source-repositories#section-4
版本控制系统 – 总结
虽然目前市场上有着许多版本控制系统方案，但分布式方案明显更受欢迎。分布式 VCS 的范式为 DevOps 团队提供了灵活性，为开发者进行本地开发赋能，并在直接沟通可能存在障碍的情况下支持开发者间的分布式协作，从而更好地支持日益普遍的远程办公文化。
每个组织必须分析集中式与分布式解决方案的优势并判断出最适合自己的方案，同时为了确保架构正确还必须对相应的托管模式进行评估；权衡支撑内部方案所需的成本与选择托管产品带来的便利性以及自主能力缺失问题。
