git版本控制（Git基础关于版本控制）
git版本控制（Git基础关于版本控制）这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。集中式版本控制系统示意图， 可以多人协同办公本地版本控制系统示意图，只能单机工作。 接下来遇到的问题是，如何让在不同的电脑上的开发者协同工作。 于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。这类系统，诸如 SVN（
目标：- 了解版本控制工具的背景知识
- 了解 Git 是什么
什么是版本控制 ？版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。
如果你是一位网页设计师，可能会需要页面布局文件的所有修订版本，采用版本控制系统（VCS）是一个非常明智的选择！有了它你就可以将选定的文件回溯到之前的状态，甚至将整个项目都退回到过去某个时间点的状态，你可以比较文件的变化细节，查出是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能的缺陷等等。使用版本控制系统意味着：就算你乱来一起把整个项目中的文件夹改的改删的删，你照样可以轻松地恢复到原先的样子，但几乎不增加什么工作量！
本地版本控制系统许多人习惯用复制整个项目目录的方式来保存不同的文件版本，或许还会修改名字加上备份时间等以示区别。这个做唯一的好处就是简单，但是特别容易犯错。有时候会混淆所在的工作目录，一不小心会写错文件或者意外地覆盖一些文件。
为了解决这个问题，很久之前就开发了许多中本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。
本地版本控制系统示意图，只能单机工作。
集中式版本控制系统接下来遇到的问题是，如何让在不同的电脑上的开发者协同工作。 于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。
这类系统，诸如 SVN（Subversion），CVS（Concurent Versions System）， TFS（Team Foundation Server） 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。 这已成为很多年来版本控制系统的标准做法。
集中式版本控制系统示意图， 可以多人协同办公
这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。
分布式管理系统于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。 在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照， 而是把代码仓库完整地镜像下来，包括完整的历史记录。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。
分布式版本控制系统示意图，可以多人协同办公并且每个客户端包含完整的代码和记录
Git是什么
那么，简单地说，Git 究竟是怎样的一个系统呢？ 若你理解了 Git 的思想和基本工作原理，用起来就会知其所以然，游刃有余。 在学习 Git 时，请尽量理清你对其它版本管理系统已有的认识，如 CVS、SVN或 TFS， 这样能帮助你使用工具时避免发生混淆。尽管 Git 用起来与其它的版本控制系统非常相似， 但它在对信息的存储和认知方式上却有很大差异，理解这些差异将有助于避免使用中的困惑。
- 直接记录快照，而非差异比较
Git 和其它版本控制系统（包括 Subversion 和近似工具）的主要差别在于 Git 对待数据的方式。 从概念上来说，其它大部分系统以文件变更列表的方式存储信息，这类系统（CVS、Subversion、Perforce、Bazaar 等等） 将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异 （它们通常称作 基于差异（delta-based） 的版本控制）。
集中式版本控制系统文件变更存储示意图
Git 不按照以上方式对待或保存数据。反之，Git 更像是把数据看作是对小型文件系统的一系列快照。 在 Git 中，每当你提交更新或保存项目状态时，它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。 为了效率，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 快照流。
git文件变更存储示意图
近乎所有操作都是本地执行在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。
举个例子，要浏览项目的历史，Git 不需外连到服务器去获取历史，然后再显示出来——它只需直接从本地数据库中读取。 你能立即看到项目历史。如果你想查看当前版本与一个月前的版本之间引入的修改， Git 会查找到一个月前的文件做一次本地的差异计算，而不是由远程服务器处理或从远程服务器拉回旧版本文件再来本地处理。这也意味着你在离线的时候也可以正常工作
Git保证完整性Git 中所有的数据在存储前都计算校验和，然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层，是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件，Git 就能发现。
Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）。 这是一个由 40 个十六进制字符（0-9 和 a-f）组成的字符串，基于 Git 中文件的内容或目录结构计算出来。 SHA-1 哈希看起来是这样：
24b9da6552252987aa493b52f8696cd6d3b00373
Git 中使用这种哈希值的情况很多，你将经常看到这种哈希值。 实际上，Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。
Git 一般只添加数据你执行的 Git 操作，几乎只往 Git 数据库中 添加 数据。 你很难使用 Git 从数据库中删除数据，也就是说 Git 几乎不会执行任何可能导致文件不可恢复的操作。 同别的 VCS 一样，未提交更新时有可能丢失或弄乱修改的内容。但是一旦你提交快照到 Git 中， 就难以再丢失数据，特别是如果你定期地推送数据库到其它仓库的话。
