19 January 2017
号外号外:专注于移动端的fullPage.js来啦!!!快点我查看

这是起底Git系列的第一篇,本篇先来介绍一下版本控制的历史。

以史为鉴可以明得失 —— 李世民

解决的问题

我们在开发中可能会有下面的需求,亟待解决,而这正是版本控制所做的事

  • 回到过去
  • 改变历史
  • 古今对比
  • 并行开发
  • 谁动了我的代码

如果用一张图来总结的话,我想就是下面这张

分类

版本控制大致可以下面三类,其每一类都是一个时代的产物,按照历史规律,新生事物总会取代陈旧事物,现在处在DVCS时代,但你可能还在陈旧的公司代码见过CVCS,我们很幸运生活在这个时代

  • LVCS(Local VCS)
  • CVCS(Central VCS)
  • DVCS(Distributed VCS)

如果你不知道上面三个分类的意思,那就往下看吧,下面聊一聊每一个的历史

史前时代

不说话,写过论文的应该都懂下面这张图,在没有版本控制工具之前,聪明的我们通过手动复制解决

LVCS(Local VCS)

本地版本控制原理很简单,就是在本地建一个仓库,记录每一个版本和版本之间的关系,这就解决了我们上面手动维护的尴尬

这个时代的代表是rcs,自行百度吧

但本地版本控制有一个很大的问题,就是没法多人协作

CVCS(Central VCS)

为了解决写作的问题,聪明的程序员想了个办法,大家共用一个仓库over了吗,于是乎把仓库搬到了远端机器,大家都访问同一个远程仓库,这种模式就成为中心仓库模式

这个时代的代表工具就是SVN,这也是大部分公司还在用的工具

但这种模式有一个致命的缺点,就是中心的单点,如果服务器恰好坏了,那代码全部丢失,所以大公司一般都有很好的容灾机制

DVCS(Distributed VCS)

随着开源运动的爆发,中心仓库模式很难适应全球多人写作的模式,于是乎分布式版本控制诞生了

DVCS结合了LVCS和CVCS两者的优点,本地仓库让一切都在本地,同时分布式的设计又让每一个节点都能成为远端

DVCS的缺点也是不容忽视的,本地仓库会导致首次clone变慢,其学习曲线优点陡峭(相对而言)

总结

如果你有任何疑问的话,欢迎留言讨论;如果本系列文章对你有帮助的话,那我很荣幸,别忘了打赏哦,O(∩_∩)O哈哈~

最后感谢你的阅读,O(∩_∩)O哈哈~

继续学习

原文网址:http://yanhaijing.com/git/2017/01/19/deep-git-1/

公众号

扫码或搜索:颜海镜,最新博文优先推送
微信公众号:颜海镜


ujian