Pro Git学习笔记（一）

版本控制概括

1. 什么是版本控制？！

   　　版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。
   　　如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本（这或许是你非常渴望拥有的功能），采用版本控制系统（VCS）是个明智的选择。有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。
   　　

2. 背景介绍

   　　许多人都是用复制整个项目目录的方式保存不同的版本的，可能会加上修改的时间用以区别。这种方式简单但是容易出错，有时还会混淆所在的目录，一不小心会写错文件或者覆盖文件。于是，人们很久之前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。
   　　
   　　
   　　
   　　其中最流行的一种叫做 RCS，现今许多计算机系统上都还看得到它的踪影。甚至在流行的 Mac OS X 系统上安装了开发者工具包之后，也可以使用 rcs 命令。它的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。
   　　这产生另一个问题，就是无法与不同系统的开发者协同工作。于是，集中化的版本控制系统
   （Centralized Version Control Systems，简称 CVCS）应运而生。诸如 CVS、Subversion 以及
   Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。
   　　
   　　这样，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。而这种做法的弊端在于中央服务器的单点故障。如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
   　　于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了，像
   Git、Mercurial、Bazaar 以及 Darcs 等。客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

   　　
   　　
   　　许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分
   别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

3. Git概括

   　　直接记录快照，而非差异比较
   　　
   　　Git 和其它版本控制系统（包括 Subversion 和近似工具）的主要差别在于 Git 对待数据的方法。概念上来区分，其它大部分系统以文件变更列表的方式存储信息。这类系统（CVS、Subversion、Perforce、Bazaar 等等）将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。

   　　
   　　
   　　Git 不按照以上方式对待或保存数据。反之，Git 更像是把数据看作是对小型文件系统的一组快照。每次你提交更新，或在 Git 中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。Git 对待数据更像是一个 快照流。
   　　
   　　　
   　　这是 Git 与几乎所有其它版本控制系统的重要区别。因此 Git 重新考虑了以前每一代版本控制系统延续下来的诸多方面。Git 更像是一个小型的文件系统，提供了许多以此为基础构建的超强工具，而不只是一个简单的 VCS。
   　　
   　　近乎所有操作都是本地执行
   　　
   　　Ｇit中绝大部分操作都只需要访问本地文件和资源，一般不需要访问网络上其他的计算机信息。因为在本地就有这个项目的所有完整的历史。如：要浏览项目的历史，Git不需要外联到服务器去获取历史，然后再
   显示出来–它只需要在本地的库里读取。

   　　 Git保证完整性
   　　
   　　 Git 中所有数据在存储前都计算校验和，然后以校验和来引用。这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。这个功能建构在 Git 底层，是构成 Git 哲学不可或缺的部分。若你在传送过程中丢失信息或损坏文件，Git 就能发现。
   　　 Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）。这是一个由 40 个十六进制字符（0-9 和 a-f）组成字符串，基于 Git 中文件的内容或目录结构计算出来。Git 中使用这种哈希值的情况很多，你将经常看到这种哈希值。实际上，Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。SHA-1 哈希看起来是这样：
   　　

   24b9da6552252987aa493b52f8696cd6d3b00373

   　　三种状态
   　　
   　　Git 有三种状态，你的文件可能处于其中之一：已提交（committed）、已修改（modified）和已暂存（staged）。已提交表示数据已经安全的保存在本地数据库中。已修改表示修改了文件，但还没保存到数据库中。已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。
   　　由此引入 Git 项目的三个工作区域的概念：Git 仓库、工作目录以及暂存区域。
   　　
   　　
   　　
   　　Git 仓库目录是 Git 用来保存项目的元数据和对象数据库的地方。这是 Git 中最重要的部分，从其它计算机克隆仓库时，拷贝的就是这里的数据。
   　　工作目录是对项目的某个版本独立提取出来的内容。这些从 Git 仓库的压缩数据库中提取出来的文件，放在磁盘上供你使用或修改。
   　　暂存区域是一个文件，保存了下次将提交的文件列表信息，一般在 Git 仓库目录中。有时候也被称作`‘索引’’，不过一般说法还是叫暂存区域。
   　　基本的 Git 工作流程如下：
   　　 　- 在工作目录中修改文件
   　　　 - 暂存文件，将文件的快照放入暂存区域
   　　　 - 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录
   　　　
   　　如果 Git 目录中保存着的特定版本文件，就属于已提交状态。如果作了修改并已放入暂存区域，就属于已暂存状态。如果自上次取出后，作了修改但还没有放到暂存区域，就是已修改状态
   　　
   　　安装 Git
   　　
   　　因为本人用ｗｉｎｄｏｗ系统，则只介绍其在ｗｉｎｄｏｗ下的安装。
   　　在 Windows 上安装 Git 也有几种安装方法。官方版本可以在 Git 官方网站下载。打开 http://git-
   scm.com/download/win，下载会自动开始。要注意这是一个名为 Git for Windows的项目（也叫做
   msysGit），和 Git 是分别独立的项目；更多信息请访问 http://msysgit.github.io/。另一个简单的方法是安装 GitHub for Windows。该安装程序包含图形化和命令行版本的 Git。它也能支持Powershell，提供了稳定的凭证缓存和健全的 CRLF 设置。

   　　初次运行 Git 前的配置
   　　
   　　Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。这些变量存储在三个不同的位置：
   　　1. /etc/gitconfig 文件: 包含系统上每一个用户及他们仓库的通用配置。 如果使用带有 –system 选项的git config 时，它会从此文件读写配置变量。
   　　2. ~/.gitconfig 或 ~/.config/git/config 文件：只针对当前用户。 可以传递 –global 选项让 Git
   读写此文件。
   　　3. 当前使用仓库的 Git 目录中的 config 文件（就是 .git/config）：针对该仓库。
   　　每一个级别覆盖上一级别的配置，所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。在 Windows 系统中，Git 会查找 $HOME 目录下（一般情况下是 C:\Users\$USER）的 .gitconfig 文
   件。Git 同样也会寻找 /etc/gitconfig 文件，但只限于 MSys 的根目录下，即安装 Git 时所选的目标位置。

   　　用户信息
   　　
   　　当安装完 Git 应该做的第一件事就是设置你的用户名称与邮件地址。这样做很重要，因为每一个 Git 的提交都会使用这些信息，并且它会写入到你的每一次提交中，不可更改：

$ git config –global user.name John Doe

$ git config –global user.email [e-mail]　　

$ git config –list (检查配置信息)

总结　

　　你应该已经对 Git 是什么、Git 与你可能正在使用的集中式版本控制系统有何区别等问题有了基本的了解。现在，在你的个人系统中应该也有了一份能够工作的 Git 版本。