Git是分布式版本控制工具，也有 集中式版本控制工具。其性能优于Subversion、CVS、Perforce和 ClearCase等版本控制工具。

1.1 何为版本控制

1.2 集中式版本控制工具

代表有 CVS、 SVN（Subversion）、VSS

集中化的版本控制系统诸如CVS、SVN等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。这种做法带来了许多好处,每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个集中化的版本控制系统，要远比在各个客户端上维护本地数据库来得轻松容易。事分两面，有好有坏。这么做显而易见的缺点是中央服务器的单点故障。如果服务器宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。So有了分布式版本控制。

例如，程序员A写了V1版的项目然后提交到服务器，B等V1版写好后从服务器上下载V1，基于V1开发V2，然后重复上述操作。

1.3 分布式版本控制工具

Git、Mercurial、Bazaar、Darcs

每个人可以在本地进行版本控制，如A生成v1、v2、v3版，然后将最终版v3推送到远程库，然后B clone v3，基于此开发他自己的v1、v2、v3，然后重复上述操作。

像Git这种分布式版本控制工具，客户端提取的不是最新版本的文件快照，而是把代码仓库完整地镜像下来（本地库)。这样任何一处协同工作用的文件发生故障，事后都可以用其他客户端的本地仓库进行恢复。因为每个客户端的每一次文件提取操作，实际上都是一次对整个文件仓库的完整备份。

分布式的版本控制系统出现之后,解决了集中式版本控制系统的缺陷:1.服务器断网的情况下也可以进行开发（因为版本控制是在本地进行的）2.每个客户端保存的也都是整个完整的项目（包含历史记录，更加安全）。

1.4 Git由来

Linux10年里每天光手动合并他人优秀的linux改进代码就累死，BitKeeper同情他，允许linux社区免费用了三年，结果一个人破解掉了。被正主收回使用权，Linux无奈自己开发了Git（参没参照BitKeeper的代码是个秘密）。

1.5 Git工作机制

比如我大创的根目录，即sqlxy就是工作区。写在工作区的代码，即使写骂老板的话，随便写，可以删的不留痕迹。即使git add到暂存区，顾名思义，暂存，可能因为代码不是最终版本，就想来个版本控制以免写了屎山后回退不了，故有了暂存区，暂存区代码也可以删的不留痕迹，一旦commit到本地库，就像有了案底，比如你想删v3，如果有v4，你还要连带v4一起删。

1.6 Git和代码托管中心

代码托管中心是基于网络服务器的远程代码仓库，一般我们简单称为远程库。

远程库分为 基于局域网的Gitlab，适合不想开源不想代码被互联网上任意人看到。也有基于互联网的Giyhub、Gitee。

1.7 Git安装

Git Bash是命令行式，Git GUI是图形化界面。

GUI太简陋啦，会linux的人都用bash。按住ctrl+滚轮可放大/缩小字体。

git --version / git -v都可

1.8 Git的准备工作

git config --global user.name iris // 设置操作者的name

git config --global user.email affettoiris@yeah.net // 设置操作者的email

设置好后在这儿可以确认：

签名的作用是区分不同操作者身份。用户的签名信息在每一个版本的提交信息中能够看到，以此确认本次提交是谁做的。Git首次安装必须设置一下用户签名，否则无法提交代码。这里设置用户签名和将来登录GitHub(或其他代码托管中心）的账号没有任何关系。

2.1 初始化本地库

你想用Git管理工作区，那你得让Git获取该目录的管理权，否则报错：fatal: not a git repository (or any of the parent directories): .git。由git init来实现。

类似在文件夹里输cmd快速进入指定目录下的cmd，你在某目录里通过右键的git bash进入git，目录是指定好的。

win里半透明的文件夹代表隐藏的项目。

Git也是由linux大佬开发的，所以linux的命令，自然也适用Git。

2.2 查看本地库状态

三行日志分别在说：当前在master分支；你还没有commit过；你还没有可以commit的文件。

vim的赋值粘贴一整行：esc退出insert模式，在输:wq的地方输入yy代表复制原光标所在行，再按p就换行粘贴了。

当然，Linux的cat filename 和tail -n 数字 filename 和 clear等也是OK的。 // tail -n 4 ./Hello.txt 表示查看文件的末尾四行

当我们造了个文件后在查看状态;

提示有未追踪的文件，红色标记表示文件只存在于工作区，未追踪（即加入到暂存区）。什么都没提交但存在未追踪文件。

2.3 Git Add FileName

Linux里的换行是LF，win则是CRLF。

再次打印状态：

绿色表示Git追踪到该文件了（该文件进入暂存区了）。git提示，你若不喜欢它，可以从暂存区里踢掉它：

git rm --cached fileName 但是仅踢出暂存区，你ll发现文件还在工作区。

2.4 Git Commit [-M "日志信息"] FileName

建议不要省日志信息，不然他会强制你进入vim界面输入日志信息。

5fb7553就是版本号。一个文件被改变，插入了6行。日志信息"my first commit"

nothing to commit, working tree clean代表你有提交，且自该提交后没有内容被改变，工作树很干净。

2.5 Git Reflog / Git Log

参考ref日志log

版本号 （头指向了master分支） 日志信息是"my first commit"

git log则更详细些了，完整的版本号其实很长，跟Hash一样长，5fb7553其实是截取了七位的版本号。你还可以看到作者和提交日期。

2.6 Commit后更改过内容

红色代表未追踪。更改未被暂存以用于提交。然后我们再提交：

我明明是替换了某一行，提示1 file changed, 1 insertion(+), 1 deletion(-) 因为替换一行可以看作是为将该行delete后insert一行新的。

看到HEAD的指针指向了第二次提交了，两次提交分别是两个版本号。

2.7 总结

代码只是保存在工作区，git status是red，git add后是green，git commit -m "" 后是nothing to commit, working tree clean

2.8 版本穿梭

假设我有三次提交：

现在老板嫌v3不好，要回退到v2：

发现HEAD指针指向了v2，倒数第四行写着：reset: moving to af0afd6。

测试发现，工作区的Hello.txt的原来是v3的内容，真的回退到v2时候的内容了。

其实HEAD的指针的指向就是从这读取的。知道了当前所属分支是master后怎么知道master分支指向哪次版本？：

可见有这样的指向关系：HEAD->分支master->第N次提交