由于最近失业了，有时间思考人生的意义。平常除了在学习前端相关的知识，也关注一些哲学，今天看到黑格尔的这样一句话，存在即合理。和我昨天对代码版本控制很是适用。
说起来，软件行业这么多年来，用来管理软件版本的软件也是历尽沧桑。虽然，如今git已经成为了大家的主流工具，不过，我还是觉得想要学好一门技术还是要了解它的历史。毕竟一门工具的诞生一定有它的存在性，如果是一门被大家都认同并且广泛使用的工具，那么一定存在着它的合理性。优秀的工具一定是简化了人们的精力的付出（会有更多的精力去干什么）那么Git的诞生到底是处于什么目的呢？方便了谁？又有什么作用？（1）sccs（最早的版本控制）最早的版本控制是SCCS（SCCS Source Code Control ）
SCCS的出现为了更好的“产出”Unix，它实现的核心思路是：每个源文件都对应着一份 SCCS 格式的文件，SCCS file format 存储了对应源文件的版本变化内容，而存储方法的实现核心是 Interleaved deltas (然而 并不知道这个词该怎么翻译)。思想是：
如果在文件的版本一中
foobar在文件的版本二中
barbaz则对应的 SCCS 格式则是
^AI 1^AD 2foo^AE 2bar^AI 2baz^AE 2^AE 1Interleaved deltas 是以变动的单位是行（lines），**即如果该行中有且只有 1 个字符改动了，那么控制版本记录的是先删掉整行内容，再将改动后的新行添加到原位置中。**其中 ^A 表示控制指令。 I 表示插入，D 表示删除，每个 I （插入指令）和 D（删除指令）都有应的结束指令，即 E （End）。后面的数字代表版本号。
在版本一中增加 foo，并在版本二中删除 foo。
在版本一中增加 bar
在版本二中增加 baz（2）rcs（本地版本控制系统）Revision Control System
原理：在硬盘上(本地，local computer)保存补丁集(文件修订前后的变化)，通过所有的补丁，可以计算出各个版本的文件内容。
（3）vss（开发软件）Visual Source Safe
VSS 的全称为 Visual Source Safe 。作为 Microsoft Visual Studio 的一名成员，它主要任务就是负责项目文件的管理，几乎可以适用任何软件项目。管理软件开发中各个不同版本的源代码和文档，占用空间小并且方便各个版本代码和文档的获取,对开发小组中对源代码的访问进行有效的协调。（4）cvs（目前基本快要淘汰了）Concurrent Version System(并行版本系统)
www.cvsnt.org（跳转到了https://www.march-hare.com/cvspro/）（服务端）
http://www.tortoisecvs.org/（客户端）
（5）svn（集中化版本控制系统）Apache Subversion
原理：在一个单一的集中管理的服务器(central server)，保存所有文件的修订版本。协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。
https://subversion.apache.org/（服务端）
https://tortoisesvn.net/（客户端）
（6）Mercurial（轻量级分布式版本控制系统）https://www.mercurial-scm.org/
Mercurial 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。其是基于 GNU General Public License (GPL) 授权的开源项目
。
（7）git（分布式版本控制系统）原理：客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。每一次的克隆操作，实际上都是一次对代码仓库的完整备份。
git相比svn的主要优点：
svn保存的是一份最新的资源，当central server数据丢失时，客户端拥有的资源只能保证最新的代码资源不丢，而代码此前的更改记录，即历史提交记录，都无法恢复。
git保存的则是服务器上所有的数据，包括工程建立之初，一直到clone之时的所有版本资源。每一个客户端，都保存了完整的历史记录及提交日志等。
总结版本控制工具经历了 SCCS → RCS → 以 CVS 为开端的集中式 → 以 Git 为主流的分布式
工具的迭代和流行一定存在着合理的原因，希望自己能够不只是单单掌握工具的使用，而且可以把握住整个工具变迁的过程，体会开发者们设计的思想。
本文来自投稿，不代表展天博客立场，如若转载，请注明出处：https://www.me900.com/326021.html
