Git——版本控制概论(一)

随着信息技术的发展,软件开发已不是小手工作坊,软件的规模和复杂度已经不再适合一个人单打独斗的开发了,

团队协作变得相当重要,如果没有VCS版本控制系统Version Control System),团队开发就会变得乱七八糟。

1.版本控制概论

版本控制是记录我们对文件、目录或工程等修改的历史,方便查看更改历史,备份以便恢复以前的版本,多人协作。

最早的版本控制是纯手工的版本控制:修改文件,保存文件副本。

由于许多时候偷懒省事,保存副本文件名比较随意,时间一长就不知道哪个是哪个了。

由于手工管理比较麻烦且混乱,后来就出现了本地版本控制,记录文件每次的更新,可以对每个版本做一个快照,或是记录补丁文件。

但是本地版本控制系统偏向于个人使用,或者多个使用的人必须使用相同的设备,如果需要多人协作那就不好办了。

于是乎,集中版本控制(Centralized Version Control Systems,简称CVCS)应运而生。

在CVCS中,所有版本数据都保存在服务器上,一起工作的人从服务器上同步更新或上传自己的修改。

但是,所有版本数据都保存在服务器上,用户要获取最新版本就需要从中心服务器上下载,如果网络的带宽高还好,否则会非常麻烦。

同时查看历史版本也必须联网,如果不联网就看不到历史版本,无法切换版本验证问题,或不能在不同分支工作。

而且,所有数据都保存在一台服务器上,数据面临丢失的风险。

针对CVSC的以上缺点,就出现了分布式的版本控制(Distributed Verson Control System,简称DVCS),常用的有Git、Mercurial等。

DVCS不是复制指定版本的快照,而是把所有的版本信息仓库全部同步到本地,这样就可以在本地查看所有的历史版本,

可以离线在本地提交,只需要在联网时推送到相应的服务器或其它用户那里。

由于每个用户那里保存的都是所有的版本数据,所以只要一个用户的设备没有问题就可以恢复所有数据。

当然,这增加了本地存储空间的占用。

2.集中式VS分布式

由于在实际生产中基本上都是使用集中式或分布式的版本控制,所以下面会分析一下各自的优缺点。

(1)集中式版本控制系统

集中式的版本控制系统的版本库是集中存放在中央服务器,而干活的时候,用的都是自己的电脑,

所以先要从中央服务器取得最新的版本,然后开始干活,干完活后,再把自己的或推送个中央服务器。

中央服务器就好比一个图书馆,你要改一本书,必须先从图书馆借出来,然后回到家中改,改完之后再放回图书馆。

集中式版本控制最大的毛病就是必须联网才能工作,没有网你什么都做不了,而且受制于带宽。

(2)分布式版本控制

与集中式版本控制相比,分布式版本控制没有“中央服务器”,每个成员的电脑都是一个完整的版本库,

这样你工作的时候就不需要联网,因为版本库就在你自己的电脑上。那么多人是如何协作的了?

如果你修改了一个文件A,你的同时也修改了一个文件A,那么你俩之间就可以相互推送,然后决定最终的版本。

还集中式版本系统相比,分布式版本系统的安全性要高的多,因为每个人都有一个完整的库,所以某个人的电脑出了问题不打紧,

只要从别人那里复制一份就行了,而集中式的版本控制系统要是“中央服务器”出了问题,那就彻底玩完。

在实际使用分布式版本控制系统的时候,大部分时候对于两个人来说可能不在一个局域网之内,

这样两台电脑就不能直接访问,或者说双方并不是同时在线,以及其他种种原因,因此在分布式系统中需要有一台服务器充当“中央服务器”,

但是只是方便不同库之间的版本推送,没有它也能工作。

当然,我们接下来要详细介绍的Git并不是说只有不必联网这么简单。

CVS作为最早的开源而且免费的集中式版本控制系统,直到现在依然还有不少人在使用。

由于CVS自身设计的问题,会造成提交文件不完整,版本库莫名其妙损坏的情况。

同样是开源而且免费的SVN修正了CVS的一些稳定性问题,是目前使用最多的集中式版本控制系统。

Git是一种非常流行的分布式版本控制系统,也可以叫做源代码管理系统,相对于SVN来说就是分布式。

SVN需要一个中心服务器保存源代码,所有的开发者都是用客户端进而这个服务器交互。

GIt的强大之处并非在于分布式,而是其对源代码存储的机制(使用快照),

由于这样的机制的存在,你可以大量频繁的使用分支来工作,通过分支来隔离功能开发的过程。

原文地址:https://www.cnblogs.com/yangmingxianshen/p/8361369.html