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

可能很多人还没有听过 Git，也不知道版本控制系统是什么，这很正常，因为我们之前写的代码很多都是玩具代码，例如说：一开始你是写着玩的，可能写着写着就变成了一坨，想要改进无从下手，想要重写又心有不甘。

这时候你就意识到真的需要一个版本控制系统来帮助你了。因为版本控制系统事实上就是帮你把程序的开发过程分步骤的给记录起来，由于我们这个教程的定位是开发可以到可以部署到生产环境的代码，所以我们的程序不再是一两个小时就能完成的，有些代码可能需要你反复的去琢磨，去推敲、去调试，直到最后的Perfect。程序的功能也要逐步的去完善，必要的时候我们还需要对代码进行重构，所以，在真正开始一个大项目开发之前，你必须先学会世界上最好的版本控制系统——Git。它将是我们今后的超级帮手。

首先，我们来回忆一下，在没有版本控制系统之前，我们是如何管理程序的版本的呢？我相信大家和我一样，也是使用文件夹的形式。例如：在开始的时候，我们会创建一个 BigProjectV0.1 的文件夹，然后在里面写第一版的程序....。然后第二天，我们有了新的想法，想改进一下，但是我们又不敢在 BigProjectV0.1 里面改，因为改了之后，想退回去就麻烦大了，所以我们就会拷贝多一个 BigProjectV0.2。

以上就是我们非常朴素的管理程序版本的思想，我相信很多朋友在不知道有版本控制系统之前也是这么干的。但是随着代码量的增加，版本数量的增加，这种朴素的版本管理方式无疑是不靠谱的，如果你的程序是多人合作开发的话，那问题更大，因为一联网就造成了数据的互相覆盖，那到底哪个版本是谁的就搞不清楚了。

同样的问题曾经也困扰着 Git 的发明者（即Linux 的缔造者 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 去建立小型项目实在轻而易举。

目前你手边上有没有一些将主宰软件业界未来发展的计划？

目前没有，如果有的话我会告诉你。