Git Pro深入浅出(2)

Git Pro深入浅出（二）六、Git工具1. 选择修订版本Git允许通过几种方法来指明特定的或者一定范围内的提交。

git show <commitid>git show <简短的SHA-1>SHA-1 的前几个字符就可以获得对应的那次提交，当然你提供的SHA-1 字符数量不得少于4个，并且没有歧义——也就是说，当前仓库中只有一个对象以这段SHA-1 开头。

#--abbrev-commit显示简短且唯一的值$git log--abbrev-commit--pretty=oneline（1）引用日志Git会在后台保存一个引用日志(reflog)，引用日志记录了最近几个月你的HEAD 和分支引用所指向的历史。

$ git reflog每当HEAD所指向的位置发生了变化，Git就会将这个信息存储到引用日志这个历史记录里。

# 显示制定提交记录$ git show HEAD@{21}# 显示昨天提交记录$ git show master@{yesterday}（2）祖先引用# 查看上一个提交$ git show HEAD^# 查看d921970的祖父提交$ git show d921970~2（3）提交区间# 在develop分支中而不在master分支中的提交$ git log master..develop# 在master分支中而不在develop分支中的提交$ git log develop..master# 在你当前分支中而不在远程 origin 中的提交$ git log origin/master..HEAD# 查看所有被refA或refB包含的但是不被refC包含的提交$ git log refA refB ^refC$ git log refA refB --not refC# 选择出被两个引用中的一个包含但又不被两者同时包含的提交$ git log--left-right master...develop2. 交互式暂存当你修改一组文件后，希望这些改动能放到若干提交而不是混杂在一起成为一个提交时，交互式暂存变得非常有用。

$ git add -i/--interactive3. 储藏与清理当你在项目的一部分上已经工作一段时间后，所有东西都进入了混乱的状态，而这时你想要切换到另一个分支做一点别的事情。

问题是，你不想仅仅因为过会儿回到这一点而为做了一半的工作创建一次提交。

针对这个问题的答案是git stash命令。

其会将修改的文件保存到一个栈上，而你可以在任何时候重新应用这些改动。

$ git stash$ git stash save# 查看储藏的东西$ git stash list# 重新应用储藏$ git stash apply stash@{2}注意：∙可以在一个分支上保存一个储藏，切换到另一个分支，然后尝试重新应用这些修改∙当应用储藏时工作目录中也可以有修改与未提交的文件，如果有任何东西不能干净地应用，Git会产生合并冲突。

# 从栈上删除储藏$ git stash drop stash@{2}# 应用后立即删除$ git stash pop（1）创造性的储藏不储藏任何你通过git add 命令已暂存的东西$git stash--keep-indexgit stash只会储藏已经在索引中的文件。

如果指定--include-untracked或-u标记，Git也会储藏任何创建的未跟踪文件。

$ git stash -u（2）从储藏创建一个分支$ git stash branch <branchname><stash>其创建一个新分支，检出储藏工作时所在的提交，重新在那应用工作，然后在应用成功后扔掉储藏。

是在新分支轻松恢复储藏工作并继续工作的一个很不错的途径。

（3）清理工作目录移除工作目录中所有未追踪的文件以及空的子目录（-f意味着―强制‖或―确定移除‖）。

$ git clean -f -d-n 选项来运行命令，这意味着―做一次演习然后告诉你将要移除什么‖。

$ git clean -d -n更安全的方式，将所有东西放到储藏栈中，同样达到了清理工作目录的目的。

git stash--all4. 签署工作每个人生成私钥，用生成的密钥来签署标签与提交。

5. 搜索（1）浏览代码grep命令，可以很方便地从提交历史或者工作目录中查找一个字符串或者正则表达式。

# 搜索所有文件中包含“ligang”的文件，并显示行号$ git grep -n ligang# 输出概要信息$ git grep --count ligang# 想看匹配的行是属于哪一个方法或者函数$ git grep -p js-pt-settings-user$ git grep --break --heading -p js-pt-settings-user∙–break：多个文件之间空行隔开∙–heading：文件名独占一行（2）日志搜索# 想知道是什么时候存在或者引入的静态常量"ZLIB_BUF_MAX"$ git log -SZLIB_BUF_MAX --oneline$ git log -Sligang --oneline# 行日志搜索# 查看zlib.c文件中git_deflate_bound函数的每一次变更$ git log -L :git_deflate_bound:zlib.c5. 重写历史（1）修改最后一次提交对最近一次提交，修改提交信息，或者修改你添加、修改和移除的文件的快照。

$git commit--amend注意：其修正会改变提交的SHA-1校验和，类似于一个小的变基。

如果已经推送了最后一次提交就不要修正它。

（2）修改多个提交信息为了修改在提交历史中较远的提交，必须使用更复杂的工具。

Git没有一个改变历史工具，但是可以使用变基工具来变基一系列提交。

# 在HEAD~3..HEAD范围内的每一个提交都会被重写，无论你是否修改信息$ git rebase -i HEAD~36. 重置揭密（1）三棵树理解reset和checkout的最简方法，就是以Git的思维框架（将其作为内容管理器）来管理三棵不同的树。

―树‖ 在我们这里的实际意思是―文件的集合‖，而不是指特定的数据结构。

Git 作为一个系统，是以它的一般操作来管理并操纵这三棵树的：树用途HEAD 上一次提交的快照，下一次提交的父结点Index 预期的下一次提交的快照Working Directory 沙盒HEAD：HEAD是当前分支引用的指针，它总是指向该分支上的最后一次提交。

这表示HEAD 将是下一次提交的父结点。

通常，理解HEAD 的最简方式，就是将它看做你的上一次提交的快照。

# 显示了 HEAD 快照实际的目录列表$ git cat-file -p HEADIndex：索引是你的―预期的下一次提交‖–―暂存区域‖，运行git add后，代码就进入―暂存区域‖。

# 显示出索引当前的样子$ git ls-files –sWorking Directory：可以把工作目录当做―沙盒‖。

在将修改提交到暂存区并记录到历史之前，可以随意更改。

（2）工作流程Git主要的目的是通过操纵这三棵树来以更加连续的状态记录项目的快照。

（3）重置的作用将当前的分支重设（reset）到指定的<commit>或者HEAD（默认是HEAD，即最新的一次提交），并且根据[mode]有可能更新index和working directory（默认是mixed）。

$ git reset[--hard|soft|mixed|merge|keep][commit|HEAD]A). –hard：重设index和working directory，从<commit>以来在working directory中的任何改变都被丢弃，并把HEAD指向<commit>。

$ git add test1$ git commit -m"Add test1"$ git add test2$ git commit -m"Add test2"$ git log --oneline$git reset--hard HEAD~1$ git log--oneline$ git status #没有任何内容说明：第二次提交的test2已被丢弃！HEAD指针重新指向了第一次提交的commitID。

彻底回退到某个版本，本地的源码也会变为上一个版本的内容。

B). –soft：index和working directory中的内容不作任何改变，仅仅把HEAD指向<commit>。

自从<commit>以来的所有改变都会显示在git status的“Changes to be committed”中。

$ git add test1$ git commit -m"Add test1"$ git add test2$ git commit -m"Add test2"$ git log --oneline$ git reset --soft HEAD~1#不会有任何提示$ git log --oneline$ git status说明：第二次提交的test2被重置到了‖Changes to be committed‖中！HEAD指针重新指向了第一次提交的commitID。

回退到某个版本，只回退了commit的信息。

如果还要提交，直接commit即可。

C). –mixed：仅重设index，但是不重设working directory。

这个模式是默认模式，即当不显示告知git reset模式时，会使用mixed模式。

这个模式的效果是，working directory中文件的修改都会被保留，不会丢弃，但是也不会被标记成“Changes to be committed”，但是会打出什么还未被更新的报告。

$ git add test1$ git commit -m"Add test1"$ git add test2$ git commit -m"Add test2"$ git log --oneline#不会有任何提示(默认方式，可以省略--mixed)#不会有任何提示(默认方式，可以省略--mixed)$git reset--mixed HEAD~1$git log--oneline$ git status说明：第二次提交的test2被重置到了初始状态（上述示例为―Untracked‖）！HEAD指针重新指向了第一次提交的commitID。