Git logo

Git 系列教程（一）Git 简介

1.关于版本控制

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

既然你有需要使用 Git，那相信你对备份这个词肯定不会陌生，我们对于一些文档或者工程项目一定会做备份（毕竟ctrl+z不会总能帮到你），备份的方式因人而异，很多人习惯用备份的日期或者 version1、2这样的后缀以示区别，这种方式很简单，这个可以算是最基础的手动实现的版本控制。

version-control by hand

可是，这样做的缺点也很多。

如果现在的这个版本不好用，想找回以前那版，可是谁还记得哪份文件对应哪个版本啊。。。

这么多文件，想删不敢删，如果哪天要用怎么办。。。

最要命的是，如果一个文件是很多个人共同写成的，当你拿到别人写好的文件试图合并时，哪些是共同的部分，哪些是他修改过的。。。

于是版本控制系统出现了。

2.集中式与分布式版本控制系统

先说集中式版本控制系统，诸如 CVS、SVN 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。

centralized-mode

这种做法带来了许多好处，最重要的是让协同工作以及管理变得十分方便。但是，这种做法最显而易见的缺点就是中央服务器的存在。
首先，必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，工作效率会变得极低。
另外，中央服务器的单点故障是更加严重的问题，如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。

于是，分布式版本控制系统面世了。

分布式版本控制系统中没有“中央服务器”的概念，每个人的电脑上都是一个完整的版本库。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。另外，在分布式版本控制系统中就不需要联网了，因为版本库就在你自己的电脑上。

distributed-mode

这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。

3. Git 的诞生

虽然Linux系统是由Linus创建，但事实上有着为数众多的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上。到2002年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。
到了2005年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力（这中间发生了很多事，对，很多事）。这就迫使 Linux 开源社区基于使用 BitKeeper 时的经验教训，开发出自己的版本系统，当然就是我们所要说的Git。 他们对新的系统制订了若干目标：

• 速度
• 简单的设计
• 对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
• 完全分布式
• 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

2005年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，有着令人难以置信的非线性分支管理系统。到了2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。

reference

1. Pro-Git(有各种语言版本的)