让你不再纠结GitHub：Git起步
一、关于版本控制
版本控制是一种记录若干文件内容变化，以便将来查阅特定版本修订情况的系统。我们通常仅对保存着软件源代码的文本文件做版本控制，但实际上，你可以对任何类型的文件进行版本控制。
采用版本控制系统（VCS），你就可以将某个文件回溯到之前的状态，甚至将整个项目回退到某个时间点状态；你可以比较文件变化的细节，查查最后是谁修改了哪个地方，从而导致出怪异的问题， 又是谁何时报告了谋个功能缺陷等。
二、备份文件
本地版本控制器之前，许多人喜欢用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示却别。
好处：简单。
坏处：有时候会混淆所在的工作目录，一旦弄错文件丢了数据就无法撤销恢复。
三、本地版本控制器
本地版本控制器由来是，为了解决备份文件的存在的问题，人们就开发了许多种本地版本控制系统，它大都采用某种简单的数据库来记录文件的历次更新差异。
典型代表是一种叫做rcs，它的工作原理基本上就是保存并管理文件补丁（patch）。文件补丁是一种特定格式的文件，记录着对应文件修订前后的内容变化。所以，根据每次修订后的补丁，rcs可以通过不断打补丁，计算出各个版本的文件内容。
四、集中化的版本控制系统
接下来遇到一个新问题，如何在不同系统上的开发者协同工作？于是，集中化的版本控制系统（Centrailized Version Control Systems，简称CVCS）应运而生。
这类系统的代表，如CVS，Subversion以及Perforce等。都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连接到这台服务器，取出最新的文件或者提交更新。
好处：
相对于较老式的本地VCS来说，每个人都可以在一定程度上看到项目中其他人正在在做些什么；
管理员也可以轻松掌控每个开发者的权限，并管理一个CVCS要远比在各个客户端维护本地数据库来的轻松容易。
坏处：
中央服务器的单点故障，如果宕机一小时，则在这一小时内，谁都无法提交更新，也无法协同工作。
中央服务器磁盘发生故障，碰巧备份不够及时，还是会丢失数据的风险。最坏的情况是侧地丢失整个项目的所有历史更改记录，而被客户端提取出来的某些快照数据除外。
五、分布式版本控制系统
于是分布式版本控制系统（Distributed Version Control System，简称DVCS）面世了。
在这类系统中典型的，像Git、Mercurial、以及Darcs等，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。
好处：
这么一来，任何一处协同工作用的服务器发生故障，事后可以用任何一个镜像出来的本地仓库恢复。
更进一步，这类系统都可以指定和若干不同的远端代码仓库进行交互，你就可以在同一个项目，分别和不同的小组的人相互协作。
六、Git简史
Linux内核开源项目有着众广的参与者，绝大多数的Linux内存维护工作都花在提交补丁和保存归档的繁杂事务上（1991-2002年间）。
到2002年，整个项目组开始启用分布式版本控制系统BitKeeper来管理和维护代码。
到了2005年，开发BitKeeper的商业公司同Linux内核开源社区合作关系结束，他们收回了免费BitKepper的权利。迫使Linux开源社区（特别是Linux的缔造者Linus Torvalds）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。
自从2005年以来，Git日臻成熟完善，在高度易用的同时，仍然保留着初期的设计的目标。极其适合管理大项目，有着令人难以置信的非线性分支管理系统，可以应付复制的项目开发需求。
七、Git基础
1.直接记录快照，而非差异比较
大多数其他系统：则只关心文件内容具体差异。这类系统（CVS、Subversion、Perforce、Bazaar等）每次记录有哪些文件做了更新，以及都更新了哪些行的什么内容。
Git：只关心文件数据的整体是否发生变化，并不保存这些前后的差异数据。实际上，Git更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为了提高性能，若文件没有变化，Git不会再次保存，而只是对上次保存的快照作一链接。
2.近乎所有操作都是本地执行
CVCS：用CVCS的话，差不多所有操作都需要连接网络。
Git：绝大多数操作都只需要访问本地文件和资源，不同连网。因为它在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快。
场景：
如果要浏览项目的历史，Git不同跑到外面的服务器上去取回数据，而直接从本地数据库读取后展示给你看。
如果想看一个当前版本和一个月前的版本之间有何差异，Git会取出一个月前的快照和当前文件作一次差异运算，而不同请求远程服务器来做这件事情。
如果CVCS的话，没有网络或者断开VPN你就无法做任何事情。使用Git话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，等到有了网络的时候在上传到远程仓库。
3.时刻保持数据完整性
保存数据方式：在保存到Git之前，所有数据都要进行内容的校验和计算，并将此结果作为数据的唯一标示和索引。换句话说，不可能在你修改了文件或目录之后，Git一无所知。如果文件在传输时变得不完整，或者磁盘损坏导致文件缺失，Git都能察觉。
算法原理：Git使用SHA-1算法计算数据校验和，通过对文件的内容或目录的结构计算出一个SHA-a哈希值，作为指纹字符串。该字符串由40个十六进制字符（0-9及a-f）组成，看起来是：24b9da6552252987aa493b52f8696cd6d3b00373。
实际应用：Git的工作完全依赖于这类指纹字符串，所有保存在Git数据库中的东西都是由此哈希值来做索引的，而不是靠文件名。
4.多数操作仅添加数据
因为任何一种不可逆操作，比如删除数据，都会使回退或重现历史版本变得困难重重。
在别的VCS中，若还未提交更新，就有可能丢失或者混淆一些修改的内容。
但在Git里，一旦提交快照之后，就安全不用担心丢失数据，特别养成定期推送到其它仓库习惯的话。
八、文件的三种状态
对于任何一个文件，在Git内都只有三种状态：
已提交（committed）：表示该文件已经被安全地保存在本地数据库中。
已修改（modified）：表示修改了某个文件，但还没有提交保存。
已暂存（staged）：标识把已修改的文件放在下次提交时要保存的清单中。
九、文件流转的三个工作区域
Git管理项目时，文件流转的三个工作区域：Git的工作目录、暂存区域、以及本地仓库。
Git目录：每项目都有一个Git目录，它是Git用来保存元数据和对象数据库的地方，该目录非常重要，每次克隆镜像仓库的时候，实际拷贝的就是这个目录里面的数据。
工作目录：从项目中取出某个版本的所有文件和目录，用以开始后续的工作的目录。这些文件实际上都是从Git目录中的压缩对象数据库汇总提取出来的，接下来就可以在工作目录中对这次文件进行编辑。
暂存区域：只不过是个简单文件，一般都放在Git目录中。有时候人们会把这个文件叫做索引文件，不过标准的说话是叫暂存区域。
我们可以从文件所处的位置判断状态：
如果是Git目录中保存着的特定版本文件，就属于已提交状态；
如果作了修改并放入暂存区域，就属于已暂存状态；
如果自上次取出后，做了修改单还没有放到暂存区域，就是已修改状态；
十、Git工作流程
1.在工作目录中修改某些文件。
2.对修改后的文件进行快照，然后保存到暂存区域。
3.提交更新，将保存在暂存区域的文件快照永久转存到Git目录中。
十一、Git安装
在Windows中的安装Git很轻松，只需要从http://code.google.com/p/msysgit/下载.exe安装文件，并运行。
十二、初次运行Git前的配置
Git提供了一个叫做git config的工具（实际是git -config命令，只不过可以通过git加一个名字来呼叫此命令），专门用来配置或读取相应的工作环境。而正是这些环境变量，决定了Git在各个环节具体工作方式和行为。
这些变量可以存放在一下三个不同的地方：
1./etc/gitconfi文件：系统中对所有用户都普遍适用的配置，若使用git config --system读写的就是这个文件。
2.~/.gitconfig文件：用户目录下的配置文件只适用于该用户，若使用git config --global读写的就是这个文件。
3.当前项目的git目录的配置文件（也就是工作目录中的.git/config文件）：这里的配置仅仅对当前项目有效，每一个级别的配置都会覆盖上层相同的配置，所以.git/config文件里的配置会覆盖/etc/gitconfig中的同名变量。
在Windows系统上，Git会找寻用户主目录下的.gitconfig文件，主目录即$Home变量指定的牡蛎，一般是C:\Documents and Settings\$USER。此外，Git还会尝试寻找/etc/gitconfig文件，只不多看当初Git装在什么位置，此目录作为根目录来定位。
1.用户信息
第一个要配置的是你的个人用户名称和电子邮件。这两条配置非常重要，每次Git提交时都会引用者两条信息，说明是谁提交了更新，所以会随更新内容一起被永久纳入历史记录：
使用--global选项，那么更改的配置文件就位于你用户主目录下的那个，以后你所有的项目都会默认使用这里配置的用户信息。如果在某个特定的项目中使用其他名字或邮件，只要去掉--golable宣子昂重新配置即可，新的设定保存到当前项目的.git/config文件里。
2.文本编辑器
接下来要设置的是默认使用的文本编辑器。Git需要输入一些额外的消息的时候，会自动调用一个外部文本编辑器给你用。默认会使用操作系统指定的默认编辑器，一般可能是Vi或Vim。如果你有其它偏好，比如Emacs的话，可以重新设置：
3.差异分析工具
还有一个比较常用的是，在解决合并冲突使用哪种差异分析工具，比如要改用vimdiff的话：
Git可以理解kdiff3,tkdiff,meld,xxdiff,emerge,vimdiff,gvimdiff,ecmerge，和opendiff等合并工具的输出信息。当然你也可以指定自己的开发工具。
4.查看配置信息
查看检查已有的配置信息，可以使用：
有时会看到重复的变量名，那就说明它们来自不同的配置文件（比如/etc/gitconfig和~/.gitconfig），不过最终Git实际采用最后一个。
可以直接查阅谋个环境变量的设定，只要把特定的名字跟在后面即可，如下：
5.获取帮助
想了解Git的格式工具该怎么用，可以阅读它们的使用帮助，方法有：
git help git --help
