学习任何东西都能在网络上找到如此之多的资源，当然包括大量的优秀教程。然而我发现一些教程直接跳过理论知识，直接教我们如何使用。
万变不离其宗，如果我们能够了解一些知识的原理，对于生活或者工作上的应用也就游刃有余了。
比如说我们今天要讲的git，我们不禁要思考git是什么，然后我们去百度得到下面一个结论：Git是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。
知其然更要知其所以然，所以，我们要想为什么要有git，它的原理是什么……
版本控制
我们从最基础的开始，版本控制。版本控制（Version control）系统是任何能让你了解到一个文件的历史，以及它的发展过程的系统。它更像我们对于一些文件的修改历史工具。
Git开始
Git 是一种专为处理文本文件而设计的版本控制系统。因为，归根到底，这就是代码的本质：一堆堆以某种方式联合在一起的文本文件。Git 是一个可安装应用，它允许你对你自己所做的更改进行注释，用以创建易于导航的系统历史。
那么， Git 做了什么，是简单地保存文件所做不到的呢？从根本上讲，文件保存就是一个简化的版本控制系统，但坦率地说，它并不是一个好用的系统，因为它只能前进。当然，你也许会争论“撤消”按钮可以让你的文件回滚到以前的状态。但我们都清楚，“撤消”按钮有其局限性，最明显示的是，在关闭文件时，文件的过去也随之丢失。
本地版本控制系统
想必我们都有过写文档的过程，那你一定有过这样的经历，想删除一个段落，但是又怕恢复不过来，只能复制到一个新的文档上然后继续修改，然后这样下去，就会出现若干个文档。那么当你想找回之前被删除的段落也就非常困难了。
集中化版本控制系统
接下来我们就会想到另一个问题，如果多人同时去写这个文档呢，我们怎样协同工作，当然你可以拿着U盘copy，但是这样的效率可想而知。于是集中化的版本控制系统(Centralized Version Control Systems，简称 CVCS)应运而生。
这类系统，诸如 CVS、Subversion(SVN) 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。
这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
分布式版本控制系统
事分两面，有好有坏。上面的做法最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问您将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
于是分布式版本控制系统(Distributed Version Control System，简称 DVCS)面世了。 在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。
更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。藉此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。