网上已经有很多优秀的git教程，那为什么笔者还要再写一遍呢，因为对于git的学习，很多初学者可能学过很多遍，感觉每一次都学会了但又不是很明白，再经历过无数遍学习后，笔者也决定将自己的理解过程整理为文章以供大家学习。本篇教程的内容与其他教程的内容大同小异，但是我们将以一种不同的思路去重新认识、学习它。
上面的图片基本是我们要讲的关于git使用的基本模型，如果你觉得很复杂，请不要担心，我们会慢慢得深入。
代码管理的问题
在介绍这些之前呢，我们来说一下为什么要使用git或者说用它解决了什么问题。
当我们进行一个开发任务，不论这个项目是大还是小，我们都希望能在开发过程中好好的管理他。比如说一个团队分开写，在确保你们在人物分工明确的前提下，大家只写自己的代码互不干扰，但最终也要全部汇总到一起然后再上线，那么就需要一个地方存储整个的项目。我们再开发过程中，发现了一个bug，那这个bug是在我们第五次迭代开发后才发现的，那我们怎么知道这是第几次迭代开发时产生的呢？如果我想看看第四次迭代开发的效果是不是已经找不到了？再比如说，代码要有备份，不然哪一天你的电脑由于负载严重突然自爆了，那么代码就全没了（咳咳，当然，这有些夸张）。如果你的项目由一个团队来开发，那么就更需要管理了。
综上，我们整理一下，就是在管理项目中，我们遇到了以下问题
- 记录每次迭代代码
- 团队合作开发管理
- 代码备份
当然，其实要解决上述问题也有很多方法，对于记录每次迭代代码，我们可以把每次迭代项目的整个目录分别存起来都存储起来，并在命名上改为v1.0、v2.0。对于团队合作开发管理，我们可以在一台其他电脑上存储上整个项目。对于代码备份，我们可以用u盘拷贝一份、或者再另一台电脑上存储就可以了。
这些方法是一个很好的思路，但是除了听上去很low以外，他们没有一个很好的实践性，例如，记录每次迭代代码，如果不小心写错文件将造成很严重后果。
所以就开始有人想办法去解决这个代码管理的问题。这时候就出现了版本控制系统。
本地版本控制系统
这是最先出现的版本控制系统，原理很简单，大多是采用数据库来记录文件每次的改变。
原理大概如下
当然实际原理可能还会复杂，我们每次存储的也并不是每个完整的项目，而是文件修订前后变化的集合,但我们只需要了解个大概。
这样，通过上面的方式就可以做到了迭代开发管理。
集中化的版本控制系统
解决了上面问题，接下来需要思考的问题就是，如何让开发者协同工作，这些开发者甚至工作在不同系统上。
于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS） 这类系统，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。
他的工作流程如下
这也正是我们说的，把代码存到一台电脑上然后控制版本管理，但是这也有一定问题，如果集中管理的服务器有一天突然自爆了。。。好好好，我们还是说，除了故障吧，需要维修一小时，那么这一小时内，谁都无法更新提交，也无法协同工作。当然，如果这台电脑磁盘损坏，那也代码也将再也找不到了。
分布式版本控制系统
终于，我们等来了分布式版本控制系统（DVCS）。 在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件补丁集（也就是文件快照）， 而是把代码仓库完整地镜像下来，包括完整的历史记录。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。
更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。
他的工作流程如下
终于，我们已经解决了最早提出的三个问题。
至此，我们介绍了代码管理的发展，相信你也明白了分布式版本控制的强大之处。
分布式版本控制他有借鉴了最早本地式管理的在本地记录每一次记录的特点，又改善了集中化版本管理远程库唯一的问题。
那么接下来的文章，我们将先后介绍git在本地库用来管理版本迭代的使用，以及联合远程库用来协同合作的方法。
最后，我的学习笔记和部分博客会存储在我的个人主页，欢迎大家来访~
参考文章 ：git官网