Git是谁创造的？Linus Torvalds。他是谁，LINUX之父。Git的确切含义是什么？它是一个缩写吗，不是，它是英国俚语，其义是愚蠢或者令人不愉快的人。Linus是一个大牛，大牛看世界的角度就是与众不同，以前常见的版本管理系统也就是SCM（source code management)通常都是将源码文件抽像为一个一个对象，然后对这些对象进行内容大小的管理，通过不同版本上的差异比较进行版本管理。常见的如CVS、SVN、Clearcase。其中大型企业常采用Clearcase，通常还设置一个专门的部门叫版本室或者一个专门的岗位配置管理员。但GIT的思路与众不同，GIT它是一种远程同步的文件系统。GIT将本地库与远程库隔离开，不需要时刻同步，完全由用户来决定。也就是GIT与其它版本系统最大区别就是GIT是分布式，其它通常都是C/S式。正如Linus原话如下：
Linus开发Git从某种意义上来说也是偶然的，因为以前管理内核的版本工具是Bitkeeper，后来BitKeeper在2005年不给用了，没办法，Linus只要重新造一个git，刚开始时git只有后端，并且因为缺少方便实用的前段工具，造成相当一部分LINUX内核维护人员抵制GIT，但随着GIT版本升级，一些比较便利的工具脚本加入使得GIT越来越流行，像现在Linux kernel/Android/Perl/Eclipse都采用GIT进行版本管理。GIT强调速度与效率，简单的说就是不用每一次改代码都要连接远程库，这样带来的好处就是速度和效率，当然反过来就是硬盘占用较大，特别是比较大的项目和比较多的版本历史的话，当然现在硬盘一般都在120G以上，所以这个一点都不用担心。GIT有一个官方网站www.git-scm.com.，发布的版本有WINDOWS/MAC OSX/LINUX/UNIX。对一些常用的LINUX提供了编译后版本。
所以安装GIT非常方便，比喻说Fedora(redhat/centos) 直接yum install git就行了。windows版本需要注意一些版本的区别，单纯的GIT使用可以直接使用Git for Windows,如果希望研究GIT，可以使用sysgit，其它一些具有GIT图形化工具如tortoiseGit（还需要安装msysgit提供底层支持）、smartGit，及一些集成工具会看自带如ECLIPSE中含有JGIT插件。在Centos上列出了所有GIT相关RPM包如下：
GIT安装我想不管是WINDOW还是LINUX应该都非常简单，但GIT安装后需要进行一些配置，这些配置不是说一定必要，但是对有些情况还是非常必要的，最常见的就是配置代理，我们知道很多公司都是通过代理上网，也就是只是支持http，虽然现在git默认协议GET也支持http，但是put是还是需要通过ssh的，所有在LINUX下通常我们下载一个软件代理corkscrew http://www.agroman.net/corkscrew 目前版本是2.0下载编译后会生成一个可执行文件corkscrew,接着再编写一个脚本文件git-proxy,内容如下：
----------------------------------------
#!/bin/sh
exec ~/bin/corkscrew proxyserver 1080 $*
-----------------------------------------
最后进行git 配置 git config –global core.gitproxy ‘/home/ubuntu/bin/git-proxy’
现在你可以开始使用git了，在WINDOWS可以安装免安装版本http://code.google.com/p/msysgit/downloads/list。
虽然看起来GIT不像一个版本管理系统，按作者话说是一个文件系统，但实际上其简介也自称为“the fast version control system” 或者“Git - the stupid content tracker” 。也就是说GIT到目前为止大家还是利用它的版本管理功能。那么它与其它真正的区别在哪呢？我们可以想像一下，最早我们自己开发一个程序时，没有版本管理系统，通常都是写好一个初始版本后发给别人测试，等下一个版本出来后，再发给别人。别人拿到第二个版本的代码时怎么安装后，有两种方式，一种完全替换，一种打补丁。如下图所示，一个文件在最早的LINUX上就提供了PATCH与DIFF命令。这就引起我们思考四个问题，其实这四个问题也很平常，第一个就是我们要去管理的是什么？那肯定是源码，源码是什么？在计算机上表示的就是文件。第二个就是源码放哪儿？放在本地还是放在一个公共的仓库。第三个就是源码的变动怎么来记录。第四个就是两个人同时修改一个文件，如何管理。围绕这四个问题的实现，就形成了不同的版本管理系统。也就是说一个版本版本管理系统是用来管理文档、源码及其它与项目相关的文件信息，这些改变通常可以基本时间点的顺序将其标识为版本1、2、3等（revision)。有些这些标准标识可以通过版本管理系统进行恢复、比较。如下图所示：
常见的版本管理系统分类表述如下：
1）本地版本控制系统 源码在一台机器，通过文件的差异进行保证通常是最早的RCVS管理系统，也就是打补丁。如下图所示：
2）集中化的版本控制系统，源码管理在服务端，通常称之为Repository，这里面保存了所有文件的修改版本。客户端通过连接协议和配置选项可以拿到服务端对应版本的文件拷贝，客户端拿到这个文件后才可以进行修改操作。在进行修改时，因为是多用户并行操作，需要控制读写权限。这里又区分为两种，一种是严格锁机制的，就是同时只能一个人修改，另一个人只能看不能改如Clearcase,svc。还有一种可以同时修改，但是在提交时需要进行冲突合并，如常见的CVS/SVN/Perforce等。如下图所示：
因为这种版本控制系统我们也是经常用到，这里简单介绍一些常见的SVN和CC。
2.1）SVN subversion简称SVN ,是2000年由CollabNet公司发起开发，主要是为了替换目前广泛使用的CVS，所以两者兼容性非常强。SVN的核心是一个repository，用来集中存储数据，也就是说SVN是一个集中版本控制系统。如下图所示：
从上图可以看出，SVN是一个C/S架构，客户端通常采用一些图形化的工具，而服务端通常是一些服务进程，如果还希望通过WEB访问，还需要安装定制化的Apache（支持MOD_DAV），关于安装方式相信网上一大堆，这里就不多说了，这里重点强调一下关于SVN中的几个概念：
【1】Repository，也就是说由svnserver或者svnadmin来管理的一个文件目录。Repository虽然叫仓库，但实际在服务端机器存储的方式也就是一个文件系统，是按照文件目录树结构来组织的。可以通过svccreate来创建，通过svnadmin来管理。如下图所示：
【2】访问控制，对任何一个集中式的版本系统来说，在服务端进行访问控制和消除读写冲突都是比较麻烦的事情。通常有两种方案，一种是LOCK_MODIFY-UNLOCK解决方案，这种主要是在CC中采用。其原理图如下：
这种方案很明显的缺点就是当多个客户端工作在同一个作业面上时，也就是同一个文件时，将不得不等待最先拿到写权限的人完成。在CC中它是通过分支将不同的客户端隔开，如果多个客户端使用同一个分支就不行。所以在CC中分支是非常多的。通过分支来区分开不同的客户连接。第二种方案是COPY-MODIFY-MERGE，这种方案主要是SVN、CVS采用。好处就是单个客户端在自己的工作区进行独立工作，完成后提交与别人提交的进行合并出一个最终版本。原理图如下：
这种方案的缺点就是MERGER时不能完全自动，有时候需要人工干预。其实像前面CC虽然通过分支隔开同时开发，但是提交到MAINLINE时还是需要进行合并。这里还有一个最大的缺点就是合并通常只能是文本文件，二进制文件是无法合并的。所以对二进制文件的修改绝对锁是完全必要的。
【3】访问路径，SVN的REPOSITORY访问路径是一个URL。如下图所示：
3）分布式版本控制系统，同集中式版本控制系统不同的就是每个客户端同时也是服务端镜像站点。客户端不是单纯按照分支来取一份文件快照，而是将服务端所有的数据全保存到本地。这样做有两个好处，第一是容错性好，就算服务端坏了，有客户端保存的镜像还可以恢复。第二因为所有信息都在本地，进行版本操作性能大大提升了。这种版本系统目前主要是git,mercurial,bazaar.darcs等,其原理图如下：
转播
