《GIT基础教程》PPT课件

GIT基础教程,庞志强2011.12.26,1、初识Git,Git是一款分布式版本控制系统，有别于CVS和SVN等集中式版本控制系统，Git可以让研发团队更加高效的协同工作，从而提高生产率。使用Git，开发人员的工作不会因为贫乏的遭遇提交冲突而中断，管理人员也无需为数据备份而担心。经过Linux这样庞大的项目考研之后，Git被证明可以胜任任何规模的团队。,2、Git初始化,Git的初始化首先通过下面命令查看git版本#gitversion在开始使用Git之前，我们首先要用gitconfig命令设置一下git的配置变量，主要有以下几步：（1）配置姓名，这个将在提交的时候用到#“pang”#gitconfig-globaluser.emailpang（2）设置一些别名，以便使用更为简洁的子命令#gitconfig-globalalias.cicommit（3）开启颜色显示#gitconfig-globalcolor.uitrue,创建版本库及第一次提交首先建立一个新的工作目录，并在这个目录下建立版本库#cd/path/to/my/workspace#mkdirdemo#cddemo#gitinitInitializedemptyGitrepositoryin/path/to/./demo/.git从上面初始化的输出信息来看，工作区创建了隐藏目录.git#lsaF././.git/这个隐藏的.git目录就是Git版本库下面向工作区添加文件#echo“Hello.”welcome.txt将这个文件添加到版本库#gitaddwelcome.txt这里还没有完，需要提交一次才能进入版本库#gitcommitm“initialized”提交必须有提交说明，-m参数可以直接给出提交说明,为什么会有.git目录在非工作区执行git命令会因为找不到.git目录而报错#cd/path/to/my/workspace#gitstatus在工作区建立a/b/c目录并进入#mkdirpa/b/c#cda/b/c显示版本库目录#gitrev-parse-git-dir显示工作区根目录#gitrev-parse-show-toplevel显示工作区间根目录的相对目录#gitrev-parse-show-prefix显示当前目录到工作区的深度#gitrev-parse-show-cdup,gitconfig命令的参数区别执行下面命令，将打开.git/config文件进行编辑#gitconfig-e执行下面命令，将打开/home/git/.gitconfig文件进行编辑#gitconfig-e-global执行下面命令，将打开/etc/gitconfig系统级配置文件进行编辑#gitconfig-e-system以上三个配置文件分别是Git版本库级别的配置文件、全局配置文件（用户主目录下）和系统级配置文件（/etc目录下）。其优先级别依次降低。,谁在提交？在使用Git之前我们设置了全局变量，如果不设置会出现什么后果呢执行下面命令，删除全局变量中的和user.email##gitconfig-unset-globaluser.email这样一来，关于用户的设置就被清空了，尝试一下提交#gitcommit-allow-empty-m“whodoescommit?”由于没有设置用户，会给出一段警告。查看下提交记录#gitlog可以看出Git对于用户姓名进行了大胆猜测，猜测用户为当前终端登录用户。为了保证提交者信息的准确性，需要对提交恢复用户设置#“pang”#gitconfig-globaluser.emailpang#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暂存区,master,objects,add,checkout,commit,reset,HEAD,图中左侧是工作区，右侧是版本库。版本库包括暂存区，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“%-20pt%sn”,GitDiff魔法,master,objects,Gitdiff,gitdiff-cached,HEAD,gitdiffHEAD,小结,了解Git的工作原理。了解status的用法。知道工作区，暂存区之间的区别。学会diff不同的用法。,4、Git的对象,Git里见得最多的就是40位16进制的ID号了,产看最近一次提交#gitlog-1-pretty=raw通过提交日志，我们发现一个提交里含有3个ID：commit：本次提交的唯一标示tree：本次提交所对应的目录树parent：本次提交的父提交研究git对象ID的一个重要武器就是gitcat-file命令#gitcat-file-tID查看ID类型#gitcat-file-pID查看ID内容通过这个命令就可以对历史提交进行追踪了。,对象库,Ide6956Treef58dParenta0c6,commit,Ida0c6Tree190dParent9e8a,commit,Idf58dBlobfd3c|_welcome.txt,Tree,Idfd3cHello.,Blob,对象库,ID为什么不用顺序数字,Git的提交为什么不用顺序数字而采用40位16进制，这是因为Git是一个分布式的版本控制系统。如果采用顺序递增的编号，只能保证本地版本库的唯一性，在分发的时候难免会造成冲突。所以采用40位ID可以保证编号的全球唯一。40位的ID如何访问？对于人来说，要记住40位的16进制数是很困难的，Git提供了很多方法可以方便的访问这些ID。1、不必写全ID，只采用开头部分（一般4位以上），只有不与现有其他ID冲突即可。2、使用HEAD代表最新提交，则HEAD表示HEAD的父提交HEAD5表示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显示，master2是最后一次提交#gitresetmaster2#gitlog可以发现提交历史也都恢复了。,深入了解gitreset命令,#gitreset-q-#gitreset-soft|-hard-q上面两个用法，是可选项，省略则表示是HEAD指向的提交。第一种用法包含路径，不会重置引用，也不会改变工作区，相当于取消了之前执行的gitadd命令。第二种则会重置引用，根据不同的选项可以对暂存区和工作区进行重置。-hard：替换引用；置换暂存区；置换工作区。-soft：替换引用。,小结,熟悉reset重置的用法。学会利用reflog恢复错误重置。,6、Git检出,重置命令可以更改master的游标指向，如何能够改变HEAD的指向呢？HEAD可以理解为头指针，是当前工作区的“基础版本”，当执行提交的时候，HEAD所指向的提交将作为新提交的父提交。下面查看下当前HEAD的指向。#cat.git/HEAD#gitbranch-v用gitcheckout命令检出当前提交的父提交。#gitcheckoutID查看下现在HEAD和master所对应的提交ID。#gitrev-parseHEADmaster可以看出当前头指针和master已经指向了不同的提交。即当前是处于“分离头指针”状态。,现在再做一次提交，HEAD会怎么变化呢？#touchdetached-commit.txt#gitadddetached-commit.txt#gitcommit-m“commitindetachedHEADmode.”#cat.git/HEAD#gitlog-graph-pretty=oneline可以看到HEAD指向了最新的提交，并且是建立在之前指向的提交之上的。下面切换到master分支上。#gitcheckoutmaster切换之后，HEAD重新指向了分支，而不是断头模式。但是刚才提交的日志也不见了。#gitlog-graph-pretty=noeline挽救分离头指针，因为刚才的提交未被任何分支追踪到，因此不能保证这个提交会永远存在于对象库中。#gitmergeID,深入理解gitcheckout命令,#gitcheckout-q-#gitcheckout#gitcheckout-m-b|-orphan第一种用法是可选项，如果省略则相当于从暂存区进行检出。和重置命令不同，重置一般用于重置暂存区，而检出主要是覆盖工作区。这种用法不会改变HEAD，主要用于指定版本的文件覆盖工作区的对应文件。第二种用法则会改变头指针。只要HEAD切换到一个分支上才会被跟踪，否则就会处于分离头指针状态。第二种用法主要是用于切换分支的。第三种用法主要是用来创建并切换到新的分支的。新的分支从指定的提交开始。,小结,了解检出的作用初步了解检出的用法,7、进度恢复,我们在暂存区一节保存了工作进度Git可以通过下面命令恢复工作进度。#gitstashlist#gitstashpop保存的进度都恢复了，下面进行提交。#gitcommit-m“addnewfiles:a/b/chello.txt,butleavewelcome.txt.”后悔了，重置放弃最新的提交。#gitreset-softHEAD添加welcome.txt，撤出a/b/c/hello.txt#gitaddwelcome.txt#gitresetHEADa/b/c/hello.txt,全部清除#gitreset#gitcheckout-welcome.txt#gitclean-fdstash的用法：#echoByebyewelcome.txt#echohello.hack-1.txt#gitaddhack-1.txt#gitstashsave“hackedwelcome.txt,newfilehack-1.txt”工作区恢复了原貌，修改都不见了。#echofix.hack-2.txt#gitstash现在有了两个保存进度，如何恢复第一个进度#gitstashapplystash1#gitstashclear,小结,学会stash的常用命令stashsavestashpopstashliststashapplystashclear,8、删除操作,前面讲的都是如何添加更改文件，下面是如何删除文件。首先保存下当前进度。#gitstash#gitstashapply查看下当前工作区都有哪些文件：#ls直接在工作区删除文件#rm*.txt通过下面命令，可以看到版本库中文件还在#gitls-files结论：工作区删除文件对版本库无任何影响,执行gitrm命令删除文件根据上面的输出的提示，我们应该使用gitrm命令来删除#gitrmdetached-txthack-1.txtnew-commit.txtwelcome.txt删除动作被添加到了暂存区，这时候执行提交动作，就从真正意义上执行了文件删除。#gitcommit-m“deletefilesusinggitrm.”但是，文件只是在版本库的最新提交中删除了，在历史提交中还在。可以通过下面的命令查看历史版本的文件列表。#gitls-files-with-tree=HEAD也可以查看历史版本中删除的文件内容。#gitcat-file-pHEAD:welcome.txtgitadd-u快速删除恢复下现场#gitreset-hartHEAD#gitstashapply-q#rm*.txt#gitadd-u#gitcommit-m“deletefilesusinggitadd-u.”,恢复删除的文件经过上面的操作，工作区已经没有了任何的文件。上面说过执行删除并提交，只是在提交中删除了文件，在历史版本中还存在。我们可以通过历史版本来恢复文件。执行下面命令可以恢复welcome.txt文件。#gitcat-file-pHEAD:welcome.txtwelcome.txt或者#gitshowHEAD:welcome.txtwelcome.txt当然，使用checkout命令更为简洁实用。（思考）文件已经被恢复到文件区了，提交到版本库就可以了。#gitadd-A#gitcommit-m“restorefiles.”通过再次添加删除文件是最自然的恢复方法。其他版本库如CVS也采用同样的方法。但是其他系统却会带来严重的副作用-文件变更历史被人为割裂，或者是存储空间的浪费。Git却没有这种副作用。联想下Git对象库,小结,学会删除文件的方法学会恢复删除的方法,9、Git克隆,鸡蛋不要装在一个篮子里,版本库A,版本库B,.git,.git,gitclone,A：PUSH：PULL,B：PULL：PUSH,gitclone克隆版本库主要有三种用法#gitclone#gitclone-bare#gitclone-mirror方法1是将repository指向的版本库克隆到directory目录下。文件都会检出，版本库位于工作区下的.git目录中。方法2和3创建的克隆版本库都不包含工作区，直接就是版本库的内容，这样的版本库称为裸版本库。一般约定俗成裸版本库的目录以.git为后缀，所以上面示例中将克隆出来的裸版本库目录名写作。用法3区别于用法2之处在于用法3克隆出来的裸版本库对上游版本库进行了注册，这样可以在裸版本库中使用gitfetch命令和上游版本库进行持续同步。,对等工作区#gitclone/path/./demo/path/./demo-backup#cddemo#gitcommit-allow-empty-m“test1”#gitcommit-allow-empty-m“test2”#gitpush/path/./demo-backup出错了，因为默认更新非裸版本库的当前分支是不被允许的，这将会导致暂存区和工作区与推送至版本库的提交不一致。#cddemo-backup#gitpull#gitlog-oneline-2为什么执行pull命令没有像push那么长的命令，因为在执行clone命令时，克隆出来的版本库对原版本库进行了注册。所以执行拉回的时候无需设置上游版本库的地址。,克隆裸版本库#gitclone-bare/path/./demo/path/./demo.git#cddemo#gitcommit-allow-empty-m“test3”#gitcommit-allow-empty-m“test4”#gitpush/path/./demo.git这次推送成功了，因为裸版本库不存在工作区，因此不会造成当前分支与工作区的不同。,创建生成裸版本库裸版本库不但可以通过克隆方式创建，还可以通过gitinit命令以初始化的方式创建，之后的同步与上面大同小异。#gitinit-bare/path./demo-init.git#cd/path./demo#gitpush/path./demo-init.git推送出错了，这是由于创建的是裸版本库，没有工作分支，所以无法推送。#gitpush/path./demo-init.gitmaster加上参数master，表示推送到master分支上，推送成功。#gitcommit-allow-empty