Git实用教程 1.1：什么是Git？

什么是 Git？！！

Git 是目前世界上最牛逼、最先进的分布式版本控制系统（没有之一）。

什么是版本控制系统？

还记得你用 WORD 打字的经历吗？一不小心删错了，按下快捷键 Ctrl + z 就可以撤销删除。Git 的使命也是如此，让你有无限次后悔的机会！

一个程序，出一本书，追一个女孩都不是一蹴而就的事情（其实除了最后一个，其他都不是问题，对吧？）。都需要经过不断地修改和完善……

比如《零基础入门学习Python》这个系列后边讲的开发【打飞机小游戏】，整个开发过程大概就是：

游戏主模块（main.py）
        |
我方飞机（myplane.py）
        |
敌机（enemy.py）
        |
安装子弹（bullet.py）
        |
增加补给（supply.py）

你们看到了，随着功能的增加，代码量、相关文件数量也在逐渐增多……

这样开发就会遇到一个问题：当需要修改一些代码的时候，不得已要删除另外一些代码。第二天脑袋突然被门框给夹了一下，又想恢复回昨天删除的代码，肿么办？

有些聪明的朋友可能会通过文件夹来管理程序的版本迭代：

 

但这样的管理方式未免也太原始、太 LOW 了吧……
还有，用这种管理方式的童鞋，我想问一下：你经历过绝望吗？！

Git 的诞生

偶然间你发现有 RCS、CVS、SVN 这样的版本控制系统存在，还是免费的，所以你简直乐开了花儿~

同样的事情也发生在 Linux 的缔造者 Linus Torvalds 身上。

Linux 内核开源项目有着为数众广的参与者，然而绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。 到了 2002 年，Linux 系统十周岁之际，整个项目组开始启用一个商业的分布式版本控制系统 BitKeeper 来管理和维护代码。

其实事情是酱紫的：

随着代码库体积的倍数增加，Linus 和社区的小伙伴们很难继续通过手工的方式管理内核代码……毕竟大家都是搞开源，说白了就是义务劳作，自己平时还要上班带孩子什么的，所以时间非常有限……于是 Linus 考察了好些版本控制系统，最终决定采用 BitKeeper。但 BitKeeper 是商业软件，要收费的，这明显跟开源精神不符合嘛！

所以 Linus 跟开发 BitKeeper 的商业公司（BitMover）谈判：“你看，我大学几年整了个 Linux 系统，让多少商业公司受益，你看人家小红帽现在做得家大业大，我都不收他们钱（是他们硬塞给我才勉强接受的）……老兄，我跟你说，这个时代的主流是开源，是免费，是让老百姓受益，你看，我们是不是可以……”。就这样，成功地忽悠到了 BitKeeper 的免费使用权。

可是好景不长，到了 2005 年，BitMover 公司发现 Linux 团队中有人试图破解 BitKeeper 的加密协议（哎，一群极客在一起团队，能安安分分才是有鬼咧~~~），So，BitMover 怒了，一下子收回了 Linux 社区的免费使用权。

就这样，和 BitMover 友谊的小船说翻就翻了！

哎，这要是换作我们，肯定找出这个好事者，然后拉出去游行泄愤……

但是咱 Linus 大侠注定要为我们重新定义“牛”这个字：

• 2005年4月3日：Linus 开始开发 Git
• 2005年4月6日：Git 项目对外发布
• 2005年4月7日：Git 实现作为自身的版本控制工具
• 2005年4月18日：实现多分支合并
• 2005年6月16日：Linux 内核 2.6.12 发布，Git 已经可以用于维护 Linux 核心源码
• 2005年7月26日：Linus 功成身退，将 Git 的维护工作交给另一名 Git 的主要贡献者 Junio C Hamano

自此，Git 迅速地在极客圈中流行开来，并逐渐成为最流行的分布式版本控制系统。

到了 2008 年，GitHub（http://www.github.com）网站正式上线（就是前阵子因为提供翻墙梯子而被来自某大国 DDOS 攻击的那个网站），它为开源项目免费提供 Git 存储，无数开源项目开始迁移至 GitHub（GitHub 的使用我们在后边“远程仓库”中会讲解）。

今天，GitHub 已经是世界上最大的代码存放网站和开源社区。

取代 SVN

很多公司原来都是使用 SVN 进行版本控制管理，但越来越多的公司选择将代码迁移至 Git（最具标志性的就是使用 SVN 做版本控制的 Google Code 因为干不过 GitHub，无奈关门大吉 ）。

那么你知道 SVN 和 Git 的区别在哪里吗？

最核心的区别时 SVN 是集中式的版本控制系统，而 Git 是分布式的。

集中式版本控制系统需要找一个服务器作为大本营，所有的代码都需要提交到服务器上进行统一的管理。当你需要对代码进行改动时，需要先从服务器上下载一份拷贝，修改完成之后，还需要上传回服务器。

在分布式版本控制系统中，大家都拥有一个完整的版本库，不需要联网也可以提交修改，所以中心服务器就显得不那么重要了。

那开发成员之间如何交换修改呢？

由于大家都拥有一个完整的版本库，所以只需把各自的修改推送给对方，就可以互相看到对方的修改了。

不过分布式版本控制系统一般也有一个“中心服务器”，但它只是用于方便大家的交换而已（挂了也没关系），而 GitHub 就是这么一个平台。

注：为了避免出现鬼畜的画风，我省略了中间几个箭头……

简单的来讲就好比是两个家庭，SVN 的家长比较“暴政”，要求孩子们赚得的前都要全部统一上交；而 Git 的家长比较“开明”，允许孩子们发展自己的事业，上交多少钱，什么时候上交，都是自愿的事儿。

下边看看大家是怎么说的吧：

克隆一份全新的目录以同样拥有 5 个分支来说，SVN 是同时复製 5 个版本的文件，也就是说重复 5 次同样的动作。而 Git 只是获取文件的每个版本的元素，然后只载入主要的分支（master）。在我的经验，克隆一个拥有将近一万个提交（commit），5 个分支，每个分支有大约 1500 个文件的 SVN，耗了将近 1 小时！而 Git 只用了区区的 1 分钟！

在 SVN，分支是一个完整的目录。且这个目录拥有完整的实际文件。如果工作成员想要开啟新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来进行破坏工作（安检测试），那将会像传染病一样,你改一个分支，还得让其他人重新切分支重新下载，十分狗血。而 Git，每个工作成员可以任意在自己的本地版本库开启无限个分支。举例：当我想尝试破坏自己的程序（安检测试），并且想保留这些被修改的文件供日后使用， 我可以开一个分支，做我喜欢的事。完全不需担心妨碍其他工作成员。只要我不合并及提交到主要版本库，没有一个工作成员会被影响。等到我不需要这个分支时， 我只要把它从我的本地版本库删除即可。无痛无痒。

SVN 只能有一个指定中间版本库。当这个中间版本库有问题时，所有工作成员都一起瘫痪直到版本库维修完毕或者新的版本库设立完成。而 Git 可以有无限个版本库。或者，更正确的说法，每一个 Git 都是一个版本库，区别是它们是否拥有活跃目录（Git Working Tree）。如果主要版本库（例如：GitHub 的版本库）发生了什么事，工作成员仍然可以在自己的本地版本库（local repository）提交，等待主要版本库恢复即可。工作成员也可以提交到其他的版本库！

在 SVN，当你提交你的完成品时，它将直接记录到中间版本库。当你发现你的完成品存在严重问题时，你已经无法阻止事情的发生了。如果网路中断，你根本没办法提交！而 Git 的提交完全属於本地版本库的活动。而你只需“推”（git push）到主要版本库即可。Git 的“推”其实是在执行“同步”（Sync）。

顺便附上 SVN 迁移至 Git 的工具：https://github.com/nirvdrum/svn2git