前言

我们在大学毕业写论文的时候碰到过如下的现象：

<<毕业论文第一版.doc>>

<<毕业论文第二版.doc>>

<<毕业论文第三版.doc>>

<<毕业论文最终版.doc>>

<<毕业论文完结版.doc>>

你的论文会不断地修改，不断地完善，最终达到最完美的论文，类似的问题我曾经也碰到过很多。

实际上，代码开发中也需要这样的软件来管理我们的代码，例如我们经常会碰到如下的现象:

改之前好好的，改完就报错了，也没怎么修改啊。

在这种情况下如果不能查看修改之前的代码，查找问题是非常困难的。

如果有一个软件能记录我们对文档的所有修改，所有版本，那么上面的问题讲迎刃而解。而这类软件我们一般叫做版本控制工具。

版本控制概述

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。

有了它就可以将之前提交的文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。

使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改，删的删了，这也没有关系，你也照样可以很容易地就恢复到原先的样子。但额外增加的工作量却微乎其微。

版本管理工具一般具有如下特性:

• 能够记录历史版本,回退历史版本
• 团队开发,方便代码合并

版本管理工具介绍

现在比较流行的版本管理工具是git ,但是实际上git 是近几年才发展起来的,可能有一些老的项目,还在用一些老的软件,比如svn

版本管理发展简史(维基百科)

集中化版本控制系统

接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？ 于是，集中化的版本控制系统(Centralized Version Control Systems，简称 CVCS)应运而生。 这类系统，诸如 CVS、Subversion(SVN) 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

咱们就简单的以SVN为案例介绍一下集中式版本控制系统。

工作流程如下:

• 从中央服务器远程仓库下载代码
• 修改后将代码提交到中央服务器远程仓库

优缺点:

 优点: 简单，易操作

 缺点:所有代码必须放在中央服务器  

• 服务器一旦宕机无法提交代码,即容错性较差
• 离线无法提交代码,无法及时记录我们的提交行为

分布式版本控制系统

分布式版本控制系统(Distributed Version Control System，简称 DVCS） 在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

现在比较流行的版本管理工具是git ，咱最主要学习的也是Git分布式版本控制系统。

系统仓库分为：

• 本地仓库
• 远程仓库

工作流程如下：

1. 从远程仓库中克隆或拉取代码到本地仓库(clone/pull)
2. 从本地进行代码修改
3. 在提交前先将代码提交到暂存区
4. 提交到本地仓库。本地仓库中保存修改的各个历史版本
5. 修改完成后，需要和团队成员共享代码时，将代码push到远程仓库

总结:git和svn的区别

• svn 是集中式版本控制工具,git 是分布式版本控制工具
• svn 不支持离线提交,git 支持离线提交代码

 接下来咱们就正式开始对Git的学习。

Git强大的历史（让我叹为观止）

林纳斯·本纳第克特·托瓦兹（Linus Benedict Torvalds, 1969年~ ）

很多人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。

Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？

事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！

你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？那个年代不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。

不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。而授权的前提是:Linux 社区的人不能开发具有相同功能的竞争产品!

另一方面，BitKeeper不是开源的。显然与Linux 的开源精神不相符，所以linux 社区的很多人抱怨，不愿意使用。

典型的就是 Andrew Tridgell (Samba 开发服务的创造者) 非常不满。偷偷违反了和 BitKeeper 的协议，反编译 BitKeeper 的源代码，开发了个爬虫，然后爬取信息被人发现了。BitKeeper 公司的领导非常不满意，然后开始发布消息说，(下个版本)不再为Linux 提供免费的服务。

Linus 本人就出面协调(几周或者几个月)，但是不管用，没办法。估计谈判的过程感觉到了憋屈--"吃人嘴短，拿人手软。"

Linus 本人 花了10天的时间Git 出来了，一个月之内，Linux系统的源码已经由Git管理了！

Git 出来以后毕竟是一个人做的,开始并不好用(刚开始只能用勉强可以用来形容), 还是很多人抱怨,发展了很多年都没有干过其他软件.

直到 2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub,从此git 迎来了飞速发展,当下git 已经成为了最流行的版本控制工具

Git基础和原理

直接记录快照，而非差异比较

Git 和其它版本控制系统(包括 Subversion 和近似工具)的主要差别在于 Git 对待数据的方法。 概念上来区分，其它大部分系统以文件变更列表的方式存储信息。 这类系统(CVS、Subversion、Perforce、Bazaar 等等)将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。存储每个文件与初始版本的差异，如下图所示 ：

Git 不按照以上方式对待或保存数据。 反之，Git 更像是把数据看作是对小型文件系统的一组快照。 每次你提交更新，或在 Git 中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。 为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个快照流。如下图所示 ：

这是 Git 与几乎所有其它版本控制系统的重要区别。 因此 Git 重新考虑了以前每一代版本控制系统延续下来的诸多方面。 Git 更像是一个小型的文件系统，提供了许多以此为基础构建的超强工具，而不只是一个简单的 VCS。 稍后我们在 Git 分支讨论 Git 分支管理时，将探究这种方式对待数据所能获得的益处。

近乎所有操作都是本地执行

在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。 如果你习惯于所有操作都有网络延时开销的集中式版本控制系统，Git 在这方面会让你感到速度之神赐给了 Git 超凡的能量。 因为你在本地磁盘上就有项目的完整历史，所以大部分操作看起来瞬间完成。

举个例子，要浏览项目的历史，Git 不需外连到服务器去获取历史，然后再显示出来——它只需直接从本地数据库中读取。 你能立即看到项目历史。 如果想查看当前版本与一个月前的版本之间引入的修改，Git 会查找到一个月前的文件做一次本地的差异计算，而不是由远程服务器处理或从远程服务器拉回旧版本文件再来本地处理。

这也意味着你离线或者没有 VPN 时，几乎可以进行任何操作。 如你在飞机或火车上想做些工作，你能愉快地提交，直到有网络连接时再上传。 如你回家后 VPN 客户端不正常，你仍能工作。 使用其它系统，做到如此是不可能或很费力的。 比如，用 Perforce，你没有连接服务器时几乎不能做什么事；用 Subversion 和 CVS，你能修改文件，但不能向数据库提交修改(因为你的本地数据库离线了)。 这看起来不是大问题，但是你可能会惊喜地发现它带来的巨大的不同。

Git 保证完整性

Git 中所有数据在存储前都计算校验和，然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层，是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件，Git 就能发现。

Git 用以计算校验和的机制叫做 SHA-1 散列(hash，哈希)。 这是一个由 40 个十六进制字符(0-9 和 a-f)组成字符串，基于 Git 中文件的内容或目录结构计算出来。 SHA-1 哈希看起来是这样：

24b9da6552252987aa493b52f8696cd6d3b0037

Git 中使用这种哈希值的情况很多，你将经常看到这种哈希值。 实际上，Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。

Git 一般只添加数据

你执行的 Git 操作，几乎只往 Git 库中增加数据。 很难让 Git 执行任何不可逆操作，或者让它以任何方式清除数据。 同别的 VCS 一样，未提交更新时有可能丢失或弄乱修改的内容；但是一旦你提交快照到 Git 中，就难以再丢失数据，特别是如果你定期的推送数据库到其它仓库的话。

三种状态

Git 有三种状态：

• 已提交(committed)，已提交表示数据已经安全的保存在本地数据库中
• 已修改(modified)，已修改表示修改了文件，但还没保存到数据库中
• 已暂存(staged) ，已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。

由此引入 Git 项目的三个工作区域的概念：Git 仓库、工作目录以及暂存区域。工作目录、暂存区域以及 Git 仓库如下图所示 ：

Git 仓库目录是 Git 用来保存项目的元数据和对象数据库的地方。 这是 Git 中最重要的部分，从其它计算机克隆仓库时，拷贝的就是这里的数据。

工作目录是对项目的某个版本独立提取出来的内容。 这些从 Git 仓库的压缩数据库中提取出来的文件，放在磁盘上供你使用或修改。

暂存区域是一个文件，保存了下次将提交的文件列表信息，一般在 Git 仓库目录中。 有时候也被称作‘索引’，不过一般说法还是叫暂存区域。

基本的 Git 工作流程如下：

1. 在工作目录中修改文件。
2. 暂存文件，将文件的快照放入暂存区域。
3. 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。

如果 Git 目录中保存着的特定版本文件，就属于已提交状态。 如果作了修改并已放入暂存区域，就属于已暂存状态。 如果自上次取出后，作了修改但还没有放到暂存区域，就是已修改状态。 在Git 基础一章，你会进一步了解这些状态的细节，并学会如何根据文件状态实施后续操作，以及怎样跳过暂存直接提交。

Git 的安装

Git 的下载

下载地址： Git - Downloads

附件

Git安装

1.按照附件的 顺序直接下一步傻瓜式安装即可

2.其中安装的过程中需要填写一个邮箱和用户名(任意即可)

3.注意安装完毕请重启资源管理器或者重启电脑

4.更改语言

Git 工作流程

Git 初始化

我们先初始化一个本地

• 新建测试文件夹
• 进入文件夹,然后右键创建版本库

  

此时 我们看到 

• 文件夹上多了一个绿色图标(如果没有请看Git下载代码目录没有小绿标怎么回事)
• 文件夹内部生成了一个.git 隐藏文件夹(需要设置隐藏文件夹可见)

git 流程

流程图

概念即详解

本地仓库：是在开发人员自己电脑上的Git仓库，存放我们的代码(.git 隐藏文件夹就是我们的本地仓库) 。

远程仓库：是在远程服务器上的Git仓库，存放代码(可以是github.com或者gitee.com 上的仓库，或者自己该公司的服务器)。

工作区: 我们自己写代码(文档)的地方。

暂存区: 在本地仓库中的一个特殊的文件(index) 叫做暂存区，临时存储我们即将要提交的文件。

Clone：克隆，就是将远程仓库复制到本地仓库。

Push：推送，就是将本地仓库代码上传到远程仓库。

Pull：拉取，就是将远程仓库代码下载到本地仓库，并将代码克隆到本地工作区。