git 入门一（初识）

分布式版本控制系统 & 集中式版本控制系统

 

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

 

  集中化的版本控制系统（ Centralized Version Control Systems）。这类系统，诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存全部文件的修订版本，而协同工做的人们都经过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准作，  显而易见的缺点是中央服务器的单点故障风险。

 

Git 起源

 

同生活中的许多伟大事件同样，Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众广的参与者。绝大多数的 Linux 内核维护工做都花在了提交补丁和保存归档的繁杂事务上（1991－2002年间）。到 2002 年，整个项目组开始启用分布式版本控制系统 BitKeeper 来管理和维护代码。 到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合做关系结束，他们收回了无偿使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds ）不得不吸收教训，只有开发一套属于本身的版本控制系统才不至于重蹈覆辙。他们对新的系统制订了若干目标：

• 速度
• 简单的设计
• 对非线性开发模式的强力支持（容许上千个并行开发的分支）
• 彻底分布式
• 有能力高效管理相似 Linux 内核同样的超大规模项目（速度和数据量

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

 

      Git 和其余版本控制系统的主要差异在于，Git 只关心文件数据的总体是否发生变化，而大多数其余系统则只关心文件内容的具体差别。这类系统（CVS，Subversion，Perforce，Bazaar 等等）每次记录有哪些文件做了更新，以及都更新了哪些行的什么内容.

Git 并不保存这些先后变化的差别数据。实际上，Git 更像是把变化的文件做快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍全部文件的指纹信息并对文件做一快照，而后保存一个指向此次快照的索引。为提升性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照做一连接. 这是 Git 同其余系统的重要区别。它彻底颠覆了传统版本控制的套路，并对各个环节的实现方式做了新的设计。Git 更像是个小型的文件系统

近乎全部操做都是本地执行

 Git 中的绝大多数操做都只须要访问本地文件和资源，不用连网。但若是用 CVCS 的话，差很少全部操做都须要链接网络。由于 Git 在本地磁盘上就保存着全部当前项目的历史更新，因此处理起来速度飞快。 举个例子，若是要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来，而直接从本地数据库读取后展现给你看。因此任什么时候候你均可以立刻翻阅，无需等待。若是想要看当前版本的文件和一个月前的版本之间有何差别，Git 会取出一个月前的快照和当前文件做一次差别运算，而不用请求远程服务器来作这件事，或是把老版本的文件拉到本地来做比较。

时刻保持数据完整性

保存到 Git 以前，全部数据都要进行内容的校验和（checksum）计算，并将此结果做为数据的惟一标识和索引。换句话说，不可能在你修改了文件或目录以后，Git 一无所知。这项特性做为 Git 的设计哲学，建在总体架构的最底层。因此若是文件在传输时变得不完整，或者磁盘损坏致使文件数据缺失，Git 都能当即察觉。 Git 使用 SHA-1 算法计算数据的校验和，经过对文件的内容或目录的结构计算出一个 SHA-1 哈希值，做为指纹字符串。该字串由 40 个十六进制字符（0-9 及 a-f）组成，看起来就像是： 24b9da6552252987aa493b52f8696cd6d3b00373

 

Git 的工做彻底依赖于这类指纹字串，因此你会常常看到这样的哈希值。实际上，全部保存在 Git 数据库中的东西都是用此哈希值来做索引的，而不是靠文件名。

多数操做仅添加数据

经常使用的 Git 操做大多仅仅是把数据添加到数据库。由于任何一种不可逆的操做，好比删除数据，都会使回退或重现历史版本变得困难重重。在别的 VCS 中，若还未提交更新，就有可能丢失或者混淆一些修改的内容，但在 Git 里，一旦提交快照以后就彻底不用担忧丢失数据，特别是养成按期推送到其余仓库的习惯的话。 这种高可靠性令咱们的开发工做安心很多，尽管去作各类试验性的尝试好了，再怎样也不会弄丢数据。

文件的三种状态

对于任何一个文件，在 Git 内都只有三种状态：已提交（committed），已修改（modified）和已暂存（staged）。已提交表示该文件已经被安全地保存在本地数据库中了；已修改表示修改了某个文件，但尚未提交保存；已暂存表示把已修改的文件放在下次提交时要保存的清单中。

由此咱们看到 Git 管理项目时，文件流转的三个工做区域：Git 的工做目录，暂存区域，以及本地仓库。

 

从项目中取出某个版本的全部文件和目录，用以开始后续工做的叫作工做目录。这些文件实际上都是从 Git 目录中的压缩对象数据库中提取出来的，接下来就能够在工做目录中对这些文件进行编辑。

所谓的暂存区域只不过是个简单的文件，通常都放在 Git 目录中。有时候人们会把这个文件叫作索引文件，不过标准说法仍是叫暂存区域。

基本的 Git 工做流程以下：

1. 在工做目录中修改某些文件。
2. 对修改后的文件进行快照，而后保存到暂存区域。
3. 提交更新，将保存在暂存区域的文件快照永久转储到 Git 目录中。

 

因此，咱们能够从文件所处的位置来判断状态：若是是 Git 目录中保存着的特定版本文件，就属于已提交状态；若是做了修改并已放入暂存区域，就属于已暂存状态；若是自上次取出后，做了修改但尚未放到暂存区域，就是已修改状态。到第二章的时候，咱们会进一步了解其中细节，并学会如何根据文件状态实施后续操做，以及怎样跳过暂存直接提交。

 

Windows 安装Git

 

windows 上安装安装git的安装包下载地址： http://code.google.com/p/msysgit ，完成安装以后，可使用Git Bash 命令行工具，git GUI 图形化界面工具。包括了SSH客户端。

 

初次运行git 配置

 

git 的配置按不一样的级别在不一样的目录。

--system 系统级别  保存在安装目录下的etc/gitconfig 配置文件。

--global 用户级别，保存在C:\Users\$user\.gitconfig 配置文件

默认是项目基本，保存在.git/config 配置文件中，通常用户配置名称，邮件等，差别比较工具和文件编辑器等。

 

配置用户名和email 差别比较工具 编码等

 

git config --global user.name "andyyu"

git config --global  user.email "andyyu@gmail"

 

git config --global  merge.tool  kidff3

 

git config --global core.editor  vim

 

查看用户 配置信息

 

git config --global -l

git config --list

git config user.name

 

修改和删除用户信息

 

git config --global  --reanme-section  use  user

git config --global  --remove-section user

 

git config --global --unset  user.name