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的强大之处并非在于分布式，而是其对源代码存储的机制（使用快照），

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