前言
Git 这个词相信大家并不陌生，做开发的童鞋们每天都离不开它。当然，假设你的项目中没实用到分布式，那么，你可能从未用过 Git，当然也可能没听过。只是，这不是重点，重点是这一篇文章，我们将一起谈谈 Git。从宏观上来认识 Git。
一点序
在写这篇文章之前，就一直在想该怎样定位呢？是写一篇基础一些的使用教程，还是从宏观上介绍一下 Git 的机制呢？因为近期时间非常紧，没有那么多的空余时间，因此。思来想去决定写一篇宏观上的介绍，至于基础教程嘛，网上已经有非常多了，我都看了看，写的都比我好，因此我也就没有必要再误人子弟了。
鉴于此，我的定位是，这篇文章的主要内容是在宏观上谈谈 Git 给我们带来的改变。以及 Git 的内部实现，或者说是机制吧。最后，把自己在项目中使用 Git 的感受跟大家分享一下。
版本号控制
什么是版本号控制？我为什么要关心它呢？我想我问的这个问题有点小傻了。有过开发的童鞋们这点就不用说了，假设你真的不知道，那么去 Baidu 一下吧。
那么。你知道版本号控制系统有几种吗？你考虑过为什么公司里用的是 Git 而不用 SVN 呢？或者用的是 SVN 而不用 Git 呢？先看看他们之间的差别吧。
还记得在非常早曾经，我们要备份文件、备份数据的时候，我们是怎么做的吗？反正我的做法就是，复制整个文件（目录）。复制到还有一块硬盘，或者网盘。然后自己给他们命名。这是一种纯手工的 job 。大家都知道，仅仅要是人工的反复性劳动，出错的几率会大大添加的。然而。为了解决问题，人们非常久曾经就开发了很多种本地版本号控制系统，大多都是採用某种简单的数据库来记录文件的历次更新差异。
当中最流行的一种叫做 rcs（Revision Control System）。现今很多计算机系统上都还看得到它的踪影。甚至在流行的 Mac OS X 系统上安装了开发人员工具包之后，也能够使用 rcs 命令。它的工作原理基本上就是保存并管理文件补丁（patch）。文件补丁是一种特定格式的文本文件。记录着相应文件修订前后的内容变化。所以。依据每次修订后的补丁。rcs 能够通过不断打补丁，计算出各个版本号的文件内容。
rcs 的出现大大的方便了人们对历史文件（数据）的控制和维护。然而，不久之后，又一个问题出现了。操作系统的差异，导致开发者无法进行协同工作，尤其是在版本号控制方面。
聪明的 Human 找到了解决的办法，就这样。集中式版本号控制系统（Centralized Version Control Systems。简称 CVCS）应运而生。
像这类系统。诸如 CVS。Subversion 以及 Perforce 等。都有一个单一的集中管理的server，保存全部文件的修订版本号，而协同工作的人们都通过client连到这台server，取出最新的文件或者提交更新。
多年以来，这已成为版本号控制系统的标准做法。并且在企业开发中，集中式的版本号控制系统也是最常见的、最普遍的。
这样的做法带来了很多优点，特别是相较于老式的本地 VCS 来说。如今，每一个人都能够在一定程度上看到项目中的其它人正在做些什么。而管理员也能够轻松掌控每一个开发人员的权限，而且管理一个 CVCS 要远比在各个client上维护本地数据库来得轻松easy。
古人有一句老话。叫做“福兮祸之所伏。祸兮福之所倚”。
他是说。不论什么事物都有两面性，不存在绝对的好与坏。仅仅只是是一个相对的比較罢了。
我们要追求的就是一种平衡，或者说对我们来说，利大于弊的方面而已。似乎有点跑题啊。。。回到正题。 能够看到，集中式版本号控制系统，最显而易见的缺点就是中央server的单点故障。假设宕机一小时，那么在这一小时内。谁都无法提交更新，也就无法协同工作。
要是中央server的磁盘发生问题，碰巧没做备份，或者备份不够及时。就会有丢失数据的风险。最坏的情况是彻底丢失整个项目的全部历史更改记录。而被client偶然提取出来的保存在本地的某些快照数据就成了恢复数据的希望。但这种话依旧是个问题，你不能保证全部的数据都已经有人事先完整提取出来过。
本地版本号控制系统也存在类似问题，仅仅要整个项目的历史记录被保存在单一位置，就有丢失全部历史更新记录的风险。
为什么说人类总是最聪明的呢？人类总是能解决遇到的难题。这次也不例外。
基于上述的问题。分布式版本号控制系统（Distributed Version Control System，简称 DVCS ）面世了。在这类系统中，像 Git，Mercurial，Bazaar 以及 Darcs 等，client并不仅仅提取最新版本号的文件快照。而是把代码仓库完整地镜像下来。这么一来。不论什么一处协同工作用的server发生问题，事后都能够用不论什么一个镜像出来的本地仓库恢复。由于每一次的提取操作。实际上都是一次对代码仓库的完整备份。
更进一步。很多这类系统都能够指定和若干不同的远端代码仓库进行交互。
籍此，你就能够在同一个项目中，分别和不同工作小组的人相互协作。你能够依据须要设定不同的协作流程。比方层次模型式的工作流，而这在曾经的集中式系统中是无法实现的。
思想
那么，简单地说，Git 到底是如何的一个系统呢？让我们来看看他映射出的思想。
Git 和其它版本号控制系统的主要区别在于，Git 仅仅关心文件数据的总体是否发生变化，而大多数其它系统则仅仅关心文件内容的详细差异。
这类系统（CVS，Subversion。Perforce，Bazaar 等等）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容。
Git 并不保存这些前后变化的差异数据。
实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时。它会纵览一遍全部文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能。若文件没有变化。Git 不会再次保存。而仅仅对上次保存的快照作一链接。
在 Git 中的绝大多数操作都仅仅须要訪问本地文件和资源，不用连网。
但假设用 CVCS 的话，差点儿相同全部操作都须要连接网络。由于 Git 在本地磁盘上就保存着全部当前项目的历史更新。所以处理起来速度飞快。
举个样例，假设要浏览项目的历史更新摘要，Git 不用跑到外面的server上去取数据回来，而直接从本地数据库读取后展示给你看。所以不论什么时候你都能够立即翻阅，无需等待。假设想要看当前版本号的文件和一个月前的版本号之间有何差异，Git 会取出一个月前的快照和当前文件作一次差异运算，而不用请求远程server来做这件事，或是把老版本号的文件拉到本地来作比較。
用 CVCS 的话，没有网络或者断开 VPN 你就无法做不论什么事情。但用 Git 的话，就算你在飞机或者火车上。都能够很愉快地频繁提交更新，等到了有网络的时候再上传到远程仓库。
相同，在回家的路上，不用连接 VPN 你也能够继续工作。
在保存到 Git 之前，全部数据都要进行内容的校验和（checksum）计算。并将此结果作为数据的唯一标识和索引。
换句话说。不可能在你改动了文件或文件夹之后，Git 一无所知。这项特性作为 Git 的设计哲学，建在总体架构的最底层。所以假设文件在传输时变得不完整，或者磁盘损坏导致文件数据缺失，Git 都能马上察觉。
Git 使用 SHA-1 算法计算数据的校验和，通过对文件的内容或文件夹的结构计算出一个 SHA-1 哈希值。作为指纹字符串。
该字串由 40 个十六进制字符（0-9 及 a-f）组成。
Git 的工作全然依赖于这类指纹字串，所以你会常常看到这种哈希值。实际上。全部保存在 Git 数据库中的东西都是用此哈希值来作索引的。而不是靠文件名称。
经常使用的 Git 操作大多不过把数据加入到数据库。由于不论什么一种不可逆的操作，比方删除数据，都会使回退或重现历史版本号变得困难重重。在别的 VCS 中，若还未提交更新，就有可能丢失或者混淆一些改动的内容，但在 Git 里，一旦提交快照之后就全然不用操心丢失数据，特别是养成定期推送到其它仓库的习惯的话。
对于不论什么一个文件。在 Git 内都仅仅有三种状态：已提交（committed）。已改动（modified）和已暂存（staged）。已提交表示该文件已经被安全地保存在本地数据库中了。已改动表示改动了某个文件，但还没有提交保存；已暂存表示把已改动的文件放在下次提交时要保存的清单中。
由此我们看到 Git 管理项目时。文件流转的三个工作区域：Git 的工作文件夹，暂存区域，以及本地仓库。
主要的 Git 工作流程例如以下：
- 在工作文件夹中改动某些文件。
- 对改动后的文件进行快照。然后保存到暂存区域。
- 提交更新。将保存在暂存区域的文件快照永久转储到 Git 文件夹中。
所以。我们能够从文件所处的位置来推断状态：假设是 Git 文件夹中保存着的特定版本号文件。就属于已提交状态；假设作了改动并已放入暂存区域，就属于已暂存状态；假设自上次取出后，作了改动但还没有放到暂存区域。就是已改动状态。
感受
因为 Git 是在 Linux 下开发的。主要是作为开源系统 Linux 下的分布式版本号控制系统。
只是，因为一些大神的移植，使得 Windows 下的用户也能够使用。
只是，对于兼容性来说。Windows 环境下的模拟 Git 还是略微差一点的。但这并不意味着 Windows 下 Git 的功能缺失。
仅仅只是在 Windows 下。更easy出一些让人无法预料的问题。当然，这些问题还是能够解决的，就是有点麻烦而已。
比方，在 Windows 下的文件的权限由于无法和linux上全然一致，所以用Git检出的文件权限可能显示为被更改。
另外由于 Windows 下的换行和 Linux 上也不一样，协作开发时也easy出问题。所以在 Windows 上使用 Git 的同学须要加上下面2行配置參数：
git config --global core.filemode false
git config --global core.autocrlf true
第一句是忽略文件权限的修改。
第二句是将文件checkout时自己主动把LF转成CRLF，check in 时自己主动把CRLF转成LF
当然，假设在 Windows 平台上开发。建议使用图形界面的 TortoiseGit client，而在 Java IDE 下也有对应的 Git 插件。比方在 Eclipse 下，能够通过安装插件的方式，安装 Git 。而在 IntelliJ IDEA 中，则默认安装了此插件，仅仅要在设置中勾选激活，然后进行配置就可以。
至于怎样使用 Git，这里就不再多说了，网上有大把大把的教程。
这里推荐一篇文章。讲的是怎样在 Eclipse 下使用 Git。文章地址。讲的还是挺具体的，有须要的自己去看一下。
结束语
这篇文章主要讲了 Git 宏观上的一些东西，还有 Git 的基本原理。
致力于让大家对 Git 有个主要的了解。当然。这是建立在使用过版本号控制系统的基础之上的。
并且，也不必纠结于究竟使用 SVN 还是使用 Git 的问题上。个人认为。假设是为了学习，那么最好是都了解一下。假设公司里有要求，那么就依照公司里的要求就可以。不是必需两款都使用。依据公司里详细的情况而定。假设，你以后打算向架构师的方向发展的话，那么就要多思考一些了，各种技术、各种工具的优势、劣势，你必须了然于胸，并且，这也是最主要的。
參考：
版权声明：本文博主原创文章，博客，未经同意不得转载。
