什么是版本控制

如果你用 Microsoft Word 写过东西，那你八成会有这样的经历：

想删除一段文字，又怕将来这段文字有用，怎么办呢？有一个办法，先把当前文件“另存为”一个文件，然后继续改，改到某个程度，再“另存为”一个文件。就这样改着、存着……最后你的 Word 文档变成了这样：

过了几天，你想找回被删除的文字，但是已经记不清保存在哪个文件了，只能挨个去找。真麻烦，眼睛都花了。看着一堆乱七八糟的文件，真想把不用的都删除，只保留一个终极版，可是又怕哪天会用上，还不敢删，真愁人。

这时候你想，要是有一个软件能帮你记录每一个版本，并且能显示出各个版本之间的差异，那多方便啊。幸运的是，这样的软件还真有，git 就是其中一个。

git 不仅具备记录版本、比较差异等最基本的功能，还支持分支、离线开发、多点开发…… 总之 git 有非常丰富而强大的功能等着你去学习与发现。如果说你学习 git 是为了收获一缕春风，那么最后你得到的将是整个春天。

集中式版本控制（Centralized Version Control ）

开发者之间的合作方式是共用一个仓库（repository），无论这个仓库是在本地还是在远端，只要是所有成员都共同存取同一个仓库，那么这种方式就是集中式（centralized）版本控制。

集中式版本控制的特点

集中式的版本控制系统其实有三大重点，即同步、追溯、以及档案的备份。
同步是为了让所有开发者对档案所做的变更都能够同步，最终得到相同的档案内容。

而追溯，则是能够回到受控档案在变化历史中的任何一个版本，并且明白每个版本间变化的原因、以及究竟做了什么变动。

至于档案的备份，无庸置疑的，就是让所有的受控档案集中保管于仓库中，作为备份也利于备份。不但能取得最新的版本，也能够取出任意时间点上的版本。

所以说，从集中式版本控制系统的设计观点来看，它主要是维持开发者之间保持同步的状态。若是根据保持同步的手段再细分，又能衍生出两种模式：一种是锁定模式，另一种是合并模式。

在锁定模式下，当开发者想要修改某档案、签出该档案后，该档案便会进入锁定状态，其他开发成员便无法加以修改，直到签出者将该档案签回为止。对于维持同步来说，这当然是一个十分保险的作法，因为永远不会有两个或以上的开发者同时修改同一个档案。只是这种方法造成了开发者对于档案修改的互斥效应，大大降低了开发效率。

因此，许多版本控制系统采用合并模式，在合并模式下，允许多位开发者同时针对同一档案进行修改，当他们分别将档案提交回仓库时，若发生冲突的情况，便会自动进行合并，而若自动合并失败，再要求人工合并。不过即使如此，最终目的还是要维持多个开发者间的同步。毕竟，版本控制的结果在集中式档案库中是唯一的，也是每位开发者都需与此结果保持一致的。

集中式版本控制的缺点

集中式版本控制系统使用起来会有什么问题呢？

首先，开发者想要签出代码、提交到仓库，或是对档案库做一些其他的操作，都必须在能够连网的环境下进行。这会大大降低开发效率。例如，你已经在本地端做好了必要的修改，想要提交到系统上，却因为正处于无法连网的环境，所以无法将档案提交出去。

当然，或许你会想，可以等到能联网之后再提交就好了。但是，我们希望每次提交的变更都是一个不可分割的最小单位，若因无法连网，无法将已完成的修改提交出去，那么也就无法继续修改其他的项目，不然应该被分为多次提交的内容就混在一块了。

如果有的开发者处在一些连网环境、速度较不佳的地区，每次存取仓库中的数据都会耗去大量的时间，这也是非常有碍效率的。

再者，由于每个开发者的修改，时常是反复持续进行，在修改的过程中，总会遇到未能稳定、完备到足以提供其他开发者使用的程度，若是在此时提交到仓库，便有可能让仓库的代码处于不稳定、不成熟的状态。当然，也可以让开发者持续修改至足够稳定完备后，再将修改内容提交至仓库。但是，在这个空窗期里，开发者就无法享受到版本控制的好处，他没有办法将修改过程中的不同阶段，划分成为多个版本。

分布式版本控制（Distributed Version Control）

由于集中式版本控制系统有一些致命的缺点，分布式（或分散式）版本控制系统应运而生，甚至慢慢成为主流。

分散式版本控制系统和集中式版本控制系统，其最大差别在于前者的仓库可以有多份。事实上，每个开发者都可以在自己的一台或者多台电脑上建立档案库。

虽然你可能认为二者都是将受控的档案储存在本地端，但其实档案库和档案在本地端的工作复本还是有很大差别的。其中最重要的意义在于档案库中包含了完整的版本管理数据、例如提交信息、版本变化记录等等。因此，所有对版本控制系统的操作，都可以直接在本机端的档案库中进行，包括提交、分支、合并、回退等。

对分散式版本控制系统来说，其核心不在于维持不同开发者间的同步，而在于让每个开发者拥有各自独立的变更集合，且开发者之间可分享自己的变更集合。

在分散式版本控制系统中，开发者可以进行“推”（push）的动作，其意义是将自身档案库中的变更送至其他的档案库；也可以进行“拉”（pull）的动作，其意义是获取其他档案库的变更。

因为每个开发者都拥有独立的档案库，所以可以直接对自己的档案库进行操作。在离线环境中，开发者既可以连续工作，也可以持续修改，和本地档案库进行交互（比如管理版本、查询修改历史、回溯、提交、……）。另一方面，开发者不需要将自己的修改持续送至集中的档案库上，造成其他开发者必须套用这些修改，引起可能的不稳定情况。

因为分散式版本控制系统本质的关系，使得此类系统更重视对分支（branch）的支持，它们通常有较好的分支及合并的能力。git 非常提倡我们利用分支来辅助日常工作流程。

有了分散式的档案库及强大的分支管理，因而衍生出多种工作流程，比如集中式（Centralized）、整合管理者式（Integration-Manager）、司令官及副官式（Dictator and Lieutenants）等等。

参考资料

[1] https://www.ithome.com.tw/node/77088
[2] https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000

集中式版本控制与分布式版本控制——Git 学习笔记01相关推荐

Git学习笔记(集中式版本控制工具与分布式版本控制工具)
集中式版本控制工具集中式版本控制工具是指所有的项目版本都存储在唯一的服务器中,而团队中使用者本地只保存有最新版本.因此,当服务器宕机或故障时,服务器中文件如果损坏或缺失,使用者本地只有最新版本,因此 ...
Git 学习笔记：5 分布式工作流程
Git 学习笔记:5 分布式工作流程分布式工作流程集中式工作流集成管理员工作流司令官与副官工作流工作流程总结向一个项目贡献提交准则私有小型团队 John's Machine 私有管理团 ...
电源架构--集中式电源架构/分布式电源架构
这里写目录标题概述隔离式电源集中式电源架构分布式电源架构: 个人理解概述 · 集中式电源架构(CPA):效率高,但成本高,PCB占用面积大. · 分布式电源架构(DPA):节省成本和PCB占 ...
多服务器分布式系统架构,集中式架构与分布式架构，你了解多少？
原标题:集中式架构与分布式架构,你了解多少? 什么是集中式集中式架构就是将项目集中存储在中央服务器中,在工作的时候,大家只要自己电脑上操作,从同一个地方下载最新版本,然后开始工作,做完的工作再提交给 ...
集中式架构vs分布式架构
个人博客原文链接历史自从20世纪60年代大型主机被发明出来以后,凭借其超强的计算和I/O处理能力以及在稳定性和安全性方面的卓越表现,在很长一段时间内,大型主机引领了计算机行业以及商业计算领域的发展 ...
Git学习笔记(一)
Git学习笔记(二) 目录一.git简介 1.1 历史 1.2 特点二.安装与配置并创建一个版本库 2.1 安装配置 2.2 创建一个版本库三.版本的创建与回退 3.1 创建一个版本 3.1.1 ...
Git学习笔记：远程仓库
前言在补习python的时候主要参考的是廖雪峰的教程Python教程,在学习完后准备完成期末作业时,遇到了一个技术难题,需要初步掌握git,因此开始了git的学习. 本教程参考廖雪峰的Git教程 G ...
Git学习笔记：修改
前言在补习python的时候主要参考的是廖雪峰的教程Python教程,在学习完后准备完成期末作业时,遇到了一个技术难题,需要初步掌握git,因此开始了git的学习. 本教程参考廖雪峰的Git教程 G ...
Git学习笔记使用记录
文章目录 Git学习笔记基本配置环境 Install 初始化workspace Git 全局设置Global Configuration: 配置账户创建项目仓库Create project re ...

集中式版本控制与分布式版本控制——Git 学习笔记01