GIT基础教程--课件.pptVIP

可以看到，不仅刚才提交的文件没了，连提交日志中的记录也不见了。使用重置命令很危险，会彻底丢掉历史。那么，利用浏览提交历史的方法找到丢弃的ID，在使用重置恢复历史吗？不可能！因为重置让提交历史也改变了。 #gitlog发现提交日志中被丢弃的提交已经不存在了。所以我们无法通过丢弃的ID来进行恢复。那么，如果不小心进行了错误的重置，应该如何去挽救呢？ *ppt课件利用reflog挽救错误重置如果没有记下被丢弃的提交ID，想要重置回原来的提交很麻烦。幸好Git提供了挽救机制。日志目录下有专门记录分支变更的文件。查看最近5次变更记录。 #tail-5.git/logs/refs/heads/master #gitreflogshowmaster|head-5根据reflog显示，master@{2}是最后一次提交 #gitresetmaster@{2} #gitlog可以发现提交历史也都恢复了。*ppt课件深入了解gitreset命令#gitreset[-q][commit][--]paths#gitreset[--soft|--hard…][-q][commit]上面两个用法，commit是可选项，省略则表示是HEAD指向的提交。第一种用法包含路径，不会重置引用，也不会改变工作区，相当于取消了之前执行的gitadd命令。第二种则会重置引用，根据不同的选项可以对暂存区和工作区进行重置。 --hard：替换引用；置换暂存区；置换工作区。 --soft：替换引用。*ppt课件小结熟悉reset重置的用法。学会利用reflog恢复错误重置。*ppt课件6、Git检出重置命令可以更改master的游标指向，如何能够改变HEAD的指向呢？HEAD可以理解为头指针，是当前工作区的“基础版本”，当执行提交的时候，HEAD所指向的提交将作为新提交的父提交。下面查看下当前HEAD的指向。 #cat.git/HEAD #gitbranch-v用gitcheckout命令检出当前提交的父提交。 #gitcheckout[ID]^查看下现在HEAD和master所对应的提交ID。 #gitrev-parseHEADmaster可以看出当前头指针和master已经指向了不同的提交。即当前是处于“分离头指针”状态。*ppt课件现在再做一次提交，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挽救分离头指针，因为刚才的提交未被任何分支追踪到，因此不能保证这个提交会永远存在于对象库中。 #gitmerge[ID] *ppt课件深入理解gitcheckout命令#gitcheckout[-q][commit][--]paths#gitcheckout[branch]#gitcheckout[-m][[-b|--orphan]new_branch][start_point]第一种用法commit是可选项，如果省略则相当于从暂存区进行检出。和重置命令不同，重置一般用于重置暂存区，而检出主要是覆盖工作区。这种用法不会改变HEAD，主要用于指定版本的文件覆盖工作区的对应文件。第二种用法则会改变头指针。只要HEAD切换到一个分支上才会被跟踪，否则就会处于分离头指针状态。第二种用法主要是用于切换分支的。第三种用法主要是用来创建并切换到新的分支的。新的分支从start_point指定的提交开始。*ppt课件小结了解检出