GIT基础教程

GIT基础教程1、初识GitGit是一款分布式版本控制系统，有别于CVS和SVN等集中式版本控制系统，Git可以让研发团队更加高效的协同工作，从而提高生产率。使用Git，开发人员的工作不会因为贫乏的遭遇提交冲突而中断，管理人员也无需为数据备份而担心。经过Linux这样庞大的项目考研之后，Git被证明可以胜任任何规模的团队。2、Git初始化Git的初始化首先通过下面命令查看git版本#git–version在开始使用Git之前，我们首先要用gitconfig命令设置一下git的配置变量，主要有以下几步：（1）配置姓名，这个将在提交的时候用到#gitconfig--globaluser.name“pang”#[e-mail]（2）设置一些别名，以便使用更为简洁的子命令#gitconfig--globalalias.cicommit（3）开启颜色显示#gitconfig--globalcolor.uitrue创建版本库及第一次提交首先建立一个新的工作目录，并在这个目录下建立版本库#cd/path/to/my/workspace#mkdirdemo#cddemo#gitinitInitializedemptyGitrepositoryin/path/to/../demo/.git从上面初始化的输出信息来看，工作区创建了隐藏目录.git#ls–aF./../.git/这个隐藏的.git目录就是Git版本库下面向工作区添加文件#echo“Hello.”welcome.txt将这个文件添加到版本库#gitaddwelcome.txt这里还没有完，需要提交一次才能进入版本库#gitcommit–m“initialized”提交必须有提交说明，-m参数可以直接给出提交说明为什么会有.git目录在非工作区执行git命令会因为找不到.git目录而报错#cd/path/to/my/workspace#gitstatus在工作区建立a/b/c目录并进入#mkdir–pa/b/c#cda/b/c显示版本库目录#gitrev-parse--git-dir显示工作区根目录#gitrev-parse--show-toplevel显示工作区间根目录的相对目录#gitrev-parse--show-prefix显示当前目录到工作区的深度#gitrev-parse--show-cdupgitconfig命令的参数区别执行下面命令，将打开.git/config文件进行编辑#gitconfig-e执行下面命令，将打开/home/git/.gitconfig文件进行编辑#gitconfig-e--global执行下面命令，将打开/etc/gitconfig系统级配置文件进行编辑#gitconfig-e--system以上三个配置文件分别是Git版本库级别的配置文件、全局配置文件（用户主目录下）和系统级配置文件（/etc目录下）。其优先级别依次降低。谁在提交？在使用Git之前我们设置了全局变量user.name，如果不设置会出现什么后果呢执行下面命令，删除全局变量中的user.name和user.email#gitconfig--unset--globaluser.name#gitconfig--unset--globaluser.email这样一来，关于用户的设置就被清空了，尝试一下提交#gitcommit--allow-empty-m“whodoescommit?”由于没有设置用户，会给出一段警告。查看下提交记录#gitlog可以看出Git对于用户姓名进行了大胆猜测，猜测用户为当前终端登录用户。为了保证提交者信息的准确性，需要对提交恢复用户设置#gitconfig--globaluser.name“pang”#[e-mail]#gitcommit--amend--allow-empty--reset-author其中--amend参数表示是修补提交，对上一次提交进行修补，而不会产生新的提交。小结•了解了Git如何初始化版本库及进行提交•熟悉Git配置变量的设置3、Git暂存区•修改能直接提交吗？首先更改welcome.txt文件，在文件后面追加一行。#echo“Nicetomeetyou.”welcome.txt比较本地与版本库中得差异#gitdiff可以看到文件修改了，那么提交#gitcommit-m“Appendaniceline.”没有成功，查看提交日志，也没用新的记录#gitlog#gitstatus-sMwelcom.txt添加下修改文件#gitaddwelcome.txt#gitdiff没有差别，难道是被提交了？在看一下当前状态：#gitstatus-sMwelcome.txt两次状态输出有细微的差别，虽然都是M（modified）标示，但是位置不一样。gitadd执行前，M位于第二列，执行后位于第一列。第一列表示版本库与暂存区的比较，第二列表示工作区与暂存区的区别。通过下面命令进一步体会：#echo“Byebye.”welcome.txt#gitstatus-sMMwelcome.txt#gitcommit-m“whichwersioncheckedin?”#gitstatus-sMwelcome.txt保存下我们的工作，后面的进度恢复会用到。#gitstash理解Git暂存区理解暂存区工作区版库本暂存区masterobjectsaddcheckoutcommitresetHEAD图中左侧是工作区，右侧是版本库。版本库包括暂存区，master分支，对象库等。HEAD实际上是指向分支的一个游标。图中objects标示的区域是Git的对象库。当对工作区的修改的文件执行gitadd命令时，暂存区的目录会被更新，同时工作区的文件会被写入到对象库中。当执行提交（gitcommit）时，master的目录树会根据暂存区做出相应的更新。当执行gitresetHEAD命令时，暂存区的目录树会被master分支的目录树所替换。当执行gitcheckout.命令时，会用暂存区的文件置换工作区的文件。（危险）当执行gitcheckoutHEAD.命令时，会用master分支的内容替换暂存区和工作区文件。（危险）目录浏览查看HEAD目录树#gitls-tree--lHEAD浏览暂存区目录树，先清除工作区改动#gitclean-fd#gitcheckout.对工作区做以下修改#echo“Bye-bye.”welcome.txt#mikdir-pa/b/c#echo“Hello.”a/b/c/hello.txt#gitadd.#echo“Bye-bye.”a/b/chello.txt#gitstatus-s#find.-path./.git-prune-o-type-printf“%-20p\t%s\n”GitDiff魔法GitDiff工作区版库本暂存区masterobjectsGitdiffgitdiff--cachedHEADgitdiffHEAD小结•了解Git的工作原理。•了解status的用法。•知道工作区，暂存区之间的区别。•学会diff不同的用法。4、Git的对象Git里见得最多的就是40位16进制的ID号了,产看最近一次提交#gitlog-1--pretty=raw通过提交日志，我们发现一个提交里含有3个ID：commit：本次提交的唯一标示tree：本次提交所对应的目录树parent：本次提交的父提交研究git对象ID的一个重要武器就是gitcat-file命令#gitcat-file-t[ID]查看ID类型#gitcat-file-p[ID]查看ID内容通过这个命令就可以对历史提交进行追踪了。数据结构对象库Ide6956Treef58dParenta0c6commitIda0c6Tree190dParent9e8acommitIdf58dBlobfd3c|_welcome.txtTreeIdfd3cHello.Blob对象库ID为什么不用顺序数字Git的提交为什么不用顺序数字而采用40位16进制，这是因为Git是一个分布式的版本控制系统。如果采用顺序递增的编号，只能保证本地版本库的唯一性，在分发的时候难免会造成冲突。所以采用40位ID可以保证编号的全球唯一。40位的ID如何访问？对于人来说，要记住40位的16进制数是很困难的，Git提供了很多方法可以方便的访问这些ID。1、不必写全ID，只采用开头部分（一般4位以上），只有不与现有其他ID冲突即可。2、使用HEAD代表最新提交，则HEAD^表示HEAD的父提交HEAD~5表示HEAD^^^^^小结•了解Git对象的概念•通过ID追踪历史提交5、Git重置我们知道，master相当于一个分支游标，每次都指向最新的提交。但是既然是游标，就应该既可以向上“游动”，也可以向下“游动”。下面来体会下master游标是怎么变化的#cat.git/refs/heads/master//查看master指向#touchnew-commit.txt#gitaddnew-commit.txt#gitcommit-m”doesmasterchange?”#cat.git/refs/heads/master下面，我们重置下master游标#gitreset--hardHEAD^#cat.git/refs/heads/master可以看到，不仅刚才提交的文件没了，连提交日志中的记录也不见了。使用重置命令很危险，会彻底丢掉历史。那么，利用浏览提交历史的方法找到丢弃的ID，在使用重置恢复历史吗？不可能！因为重置让提交历史也改变了。#gitlog发现提交日志中被丢弃的提交已经不存在了。所以我们无法通过丢弃的ID来进行恢复。那么，如果不小心进行了错误的重置，应该如何去挽救呢？利用reflog挽救错误重置如果没有记下被丢弃的提交ID，想要重置回原来的提交很麻烦。幸好Git提供了挽救机制。日志目录下有专门记录分支变更的文件。查看最近5次变更记录。#tail-5.git/logs/refs/heads/master#gitreflogshowmaster|head-5根据reflog显示，master@{2}是最后一次提交#gitresetmaster@{2}#gitlog可以发现提交历史也都恢复了。深入了解gitreset命令•#gitreset[-q][commit][--]paths•#gitreset[--soft|--hard…][-q][commit]上面两个用法，commit是可选项，省略则表示是HEAD指向的提交。第一种用法包含路径，不会重置引用，也不会改变工作区，相当于取消了之前执行的gitadd命令。第二种则会重置引用，根据不同的选项可以对暂存区和工作区进行重置。--hard：替换引用；置换暂存区；置换工作区。--soft：替换引用。小结•熟悉reset重置的用法。•学会利用reflog恢复错误重置。6、Git检出重置命令可以更改master的游标指向，如何能够改变HEAD的指向呢？HEAD可以理解为头指针，是当前工作区的“基础版本”，当执行提交的时候，HEAD所指向的提交将作为新提交的父提交。下面查看下当前HEAD的指向。#cat.git/HEAD#gitbranch-v用gitcheckout命令检出当前提交的父提交。#gitcheckout[ID]^查看下现在HEAD和master所对应的提交ID。#gitrev-parseHEADmaster可以看出当前头指针和master已经指向了不同的提交。即当前是处于“分离头指针”状态。现在再做一次提交，HEAD会怎么变化呢？#touchdetached-commit.txt#gitadddetached-commit.txt#gitcommit-m“commitindetachedHEADmod