Hello, everyone, and welcome. Thank you so much.
Today, we will teach you a very niubi skill.
That is ~~~ Git!!!
What???
什么是 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
顺便安利一下小甲鱼的新课程：《带你学C带你飞》将带你领略 Linux 和 C 的高瞻远瞩，还等什么，上车吧 -> 传送门
自此，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
彩蛋
作为首期彩蛋，小甲鱼找到了 Git 十周岁之际（2015年），Linus Torvalds 大谈 Git 的开发故事！
Git十周岁之际，Linus Torvalds 大谈 Git 开发故事！
十年前，BitMover 决定停止 BitKeeper 对 Linux 核心开发的支持，顿时 Linux 核心开发受到严峻的挑战。Linus Torvalds 整个周末不见人影，隔周却如变法戏般的带着 Git 出现。
Linus Torvalds 在 2002 年起，使用 BitMover 的版本控制软件 BitKeeper 管理 Linux 核心开发，而因为 Bitkeeper 除商业付费版本，仅提供可免费使用但不允许修改释出的精简版本，引起开源社群的不满，如自由软件之父 Richard Stallman 也严厉批评 Linus Torvalds 使用非自由软件开发 Linux 核心。
在 2005 年，Samba 文件服务器开发人 Andrew Tridgell 写了连接 BitKeeper 储存库的简单程序，被 BitMover 创办人 Larry McVoy 指控对 BitKeeper 进行逆向工程，因此决定停止 BitKeeper 对 Linux 的支持。顿时 Linux 核心开发受到严峻的挑战，而 Linus Torvalds 秉持“自己的版控自己写”精神，整个周末不见人影，隔周却如变法戏般的带着 Git 出现。在 Git 诞生十周年的近日，Linus Torvalds 接受 Linux 基金会的访问，谈论他对版本控制系统的想法及开发 Git 的过程。
为何你创造了Git？
我一直很不喜欢做源代码管理，我觉得那是计算机领域中最无趣的一件事情（也许数据库管理跟它有的比），我非常讨厌源代码管理。不过 BitKeeper（简称 BK）出现后，改变我对源代码控制的想法。BK 做对了大部分的事，它在本机端有一份完整的储存库，而且采取分布式做法非常了不起。分布式源代码控制解决了源代码控制常碰到的问题 —— 谁有资格改变源代码。借着提供储存库给每个使用者，BK 解决了这个问题。不过 BK 也有些缺陷，比方说某些技术决策引起了些问题（像是让人头痛的重新命名），但最大的缺点在于 BK 不是开放源代码，所以很多人不愿意使用。有几位我们重要维护人员因为 BK 可以免费用在开源项目上而使用它，但 BK 始终没有普遍的被使用，尽管它帮助了 Linux 核心的开发，BK 仍有不足之处。
Andrew Tridgell 违反 BK 的使用原则，对 BK 开始进行逆向工程。我花了几个礼拜或是（或是几个月），居中协调 Tridgell 跟 Larry McVoy，不过显然没有多大的帮助。从那一刻起我决定放弃使用 BK，但是我也不想回到以前没有 BK 的日子。在那时虽然也有一些源代码控制软件想采用分布式的做法，但都不成气候，它们离我效能表现的要求还差一大截，同时我担心源代码完整性及作业流程上的问题，索性决定自己写一个源代码控制系统。
你是怎么做到这件事情的？花了整个周末熬夜还是在一般时间内把 Git 搞定？
呵呵，其实你可以去 Git 源代码的储存库看它如何逐渐成形。我大概花一天让 Git 能达到自己管理自己的程度（self-hosting），之后我就开始用 Git 跟 Git 提交程序代码了。我大部分的工作都在白天完成，不过也有几天工作到深夜。我觉得最有趣的地方在看到 Git 如何快速地成形。在 Git 树中的第一次提交并没有写很多程序，但是已经实作出提交程序代码的基本功能。写 Git 并不会很难，比较难的是思考如何 Git 组织档案的方式。
我想强调，Git 从无到有大概花了我十天（包含我第一次用 Git 提交核心程序代码），而且我也不是焚膏继晷的完成 Git。这都取决对 Git 的基本概念是否很清楚，早在着手写 Git 前，我已经看到其他源代码控制系统的缺陷。我只是不想重蹈覆辙罢了。
Git 有满足你的期待吗？它有哪些地方不足？
我很喜欢 Git，它运作的非常好而且满足所有我的需求。它掌管了许多计划并且已超乎想象的速度在成长。不过看看 CVS 跟 RCS 还存在着，可见在使用者在转用其他源代码控式系统上还是有些惰性在，不过迟早有一天 Git 都会取代它们。
你认为 Git 被广为接受的原因在？
我想很多人使用其他源代码控制软件都碰到跟我类似的问题，而这些问题让我十分火光，在使用上要修正的几个小问题就让人抓狂。在 Git 未问世前，没有比较好的解决方法。许多人还不清楚分布式版本控制的好处，甚至还为此争吵不休。不过只要用过 Git，一定无法回头用其他东西。因为用 Git 备份源代码简单又可靠，而且也不必担心测试储存库是否会影响到中间储存库。
Git 会一直存在吗？在未来十年内会有其他版本控制系统出现吗？你会不会是那个系统的开发者？
我不会是那个系统的开发者，也许在十年内我们会看到类似的新东西出现，不过我敢保证，它一定会长的很像 Git。Git 并非十全十美，但是 Git 的基本设计做得非常完整，这是其他源代码管理做不到的，我没有在装客气。
为什么 Git 在 Linux 上运作的很顺？
一部分原因在于 Git 是为我们的工作流程量身打造，另一部分是我提了很多次 Git 的分布式设计，再重复几次都不为过。Git 是为有效处理庞大的项目如而生，像是 Linux。它可以处理大家以前觉得很“困难”的事，不过那些对我来说像是家常便饭。
举个例子，使用其他源代码控制系统要执行合并是非常麻烦的事情，你得精心策画，因为合并兹事体大。这我没办法接受，因为我每天都要执行一堆合并。使用 Git 合并只消几秒钟，反而是写批注花掉我比较多的时间。所以基本上 Git 是为了满足我的需求而写出来的。
很多人说 Git 是给聪明人用的，Andrew Morton（Linux 核心开发者）甚至说：“Git 的设计让使用者觉得自己比想象中的笨。”，对此你有什么样的回应？
这种说法在过去说得通，不过现在不再是了。大家会这样想会有一些原因，但是只有一个原因站得住脚：“同一件事情，Git 提供太多方法去达成。”
你可以用 Git 去做很多事情。Git 有许多规则，规范你该如何使用 Git，而这些规则跟技术关联没那么强，反而比较着墨在多人协作下如何发挥 Git 的功能。Git 是个强大的工具，所以很多人一开始会被它吓到，而因为 Git 的功能是如此强大，每次你都可以用不同的方法完成相同的事情。但一般来说，学习 Git 的最好方法是从基本开始，熟悉基础后再去摸索不一样的东西。
Git 被认为很复杂是有它的历史因素在。其中一个原因是一开始它的确很复杂。一开始使用 Git 做核心方面的工作时，用户需要配置一些脚本。当时大部分的工作都花在开发核心，比较没有精力去顾及让 Git 易于使用。诚然，Git 是很复杂，不过那也只是头一年左右的事情。
另外一个大家觉得它复杂的原因是 Git 与众不同。很多人用了 CVS 十几年，但 Git 跟 CVS 可是天差地远，不仅概念上不同，指令也不一样。Git 从来没有想要模仿 CVS，甚至想要反其道而行。如果你用类似 CVS 系统一段时间了，会觉得 Git 很复杂，甚至特立独行。比方说，为什么 Git 的版本编号不是“1.3.1”，像 CVS 那样递增的数字不是很好吗？为什么编号是恐怖的 40 字符 HEX 码？
但 Git 并不是特立独行，而是这些改进是必须的。某些人觉得复杂的原因是时代的递嬗，使用 CVS 的时代已经过去了。现在很多工程师也许会搞不清楚 CVS 的操作方法，只是因为他们先学了 Git。
如果没有 Git，Linux 核心的发展会跟现在一样好吗？
呃，没有 Git，好吧。不过一定会有人写出类似 Git 的分布式源代码控制系统，我们绝对需要像 Git 的东西。
你对 GitHub 有什么样的想法？
GitHub 提供很棒的程序代码托管服务，这方面我对它没有什么抱怨，不过我对 GitHub 比较有意见的地方是，GitHub 作为一个开发平台，它的提交、拉取要求、议题追踪等功能运作的不是很好。GitHub 有太多限制，跟核心比还差得远。一部分的原因是在核心如何被建立，另一部分原因是 GitHub 的接口会养成用户的坏习惯。因为 GitHub 接口的设计，在 GitHub 上提交会有质量不好的提交讯息等。在这方面他们做了些改善，不过永远不会适用于像 Linux 核心的东西。
你觉得 Git/GitHub 过最有趣的用途是？
使用它们建立一个新项目非常简单。以前要开启一个项目很让人头痛，但使用 Git 或 GitHub 去建立小型项目实在轻而易举。
目前你手边上有没有一些将主宰软件业界未来发展的计划？
目前没有，如果有的话我会告诉你。