|
现在，你已经学习了管理或者维护 Git 仓库，实现代码控制所需的大多数日常命令和工作流程。你已经完成了跟踪和提交文件的基本任务，并且发挥了暂存区和轻量级的特性分支及合并的威力。
接下来你将领略到一些 Git 可以实现的非常强大的功能，这些功能你可能并不会在日常操作中使用，但在某些时候你也许会需要。
6.1 修订版本（Revision）选择
Git 允许你通过几种方法来指明特定的或者一定范围内的提交。了解它们并不是必需的，但是了解一下总没坏处。
单个修订版本
显然你可以使用给出的 SHA-1 值来指明一次提交，不过也有更加人性化的方法来做同样的事。本节概述了指明单个提交的诸多方法。
简短的SHA
Git 很聪明，它能够通过你提供的前几个字符来识别你想要的那次提交，只要你提供的那部分
SHA-1 不短于四个字符，并且没有歧义——也就是说，当前仓库中只有一个对象以这段 SHA-1 开头。
例如，想要查看一次指定的提交，假设你运行 git log 命令并找到你增加了功能的那次提交：
$ git log commit 734713bc047d87bf7eac9674765ae793478c50d3 Author:
Scott Chacon <schacon@gmail.com> Date: Fri Jan 2 18:32:33 |
假设是 1c002dd.... 。如果你想 git show 这次提交，下面的命令是等价的（假设简短的版本没有歧义）：
$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b $ git show 1c002dd4b536e7479f $ git show 1c002d |
Git 可以为你的 SHA-1 值生成出简短且唯一的缩写。如果你传递 --abbrev-commit
给 git log 命令，输出结果里就会使用简短且唯一的值；它默认使用七个字符来表示，不过必要时为了避免
SHA-1 的歧义，会增加字符数：
$ git log --abbrev-commit --pretty=oneline ca82a6d changed the version
number 085bb3b removed unnecessary test code a11bef0 f |
通常在一个项目中，使用八到十个字符来避免 SHA-1 歧义已经足够了。最大的
Git 项目之一，Linux 内核，目前也只需要最长 40 个字符中的 12 个字符来保持唯一性。
关于 SHA-1 的简短说明
许多人可能会担心一个问题：在随机的偶然情况下，在他们的仓库里会出现两个具有相同
SHA-1 值的对象。那会怎么样呢？
如果你真的向仓库里提交了一个跟之前的某个对象具有相同 SHA-1 值的对象，Git
将会发现之前的那个对象已经存在在 Git 数据库中，并认为它已经被写入了。如果什么时候你想再次检出那个对象时，你会总是得到先前的那个对象的数据。
不过，你应该了解到，这种情况发生的概率是多么微小。SHA-1 摘要长度是
20 字节，也就是 160 位。为了保证有 50% 的概率出现一次冲突，需要 2^80 个随机哈希的对象（计算冲突机率的公式是p
= (n(n-1)/2) * (1/2^160))。2^80 是 1.2 x 10^24，也就是一亿亿亿，那是地球上沙粒总数的
1200 倍。
现在举例说一下怎样才能产生一次 SHA-1 冲突。如果地球上 65 亿的人类都在编程，每人每秒都在产生等价于整个
Linux 内核历史（一百万个 Git 对象）的代码，并将之提交到一个巨大的 Git 仓库里面，那将花费
5 年的时间才会产生足够的对象，使其拥有 50% 的概率产生一次 SHA-1 对象冲突。这要比你编程团队的成员同一个晚上在互不相干的意外中被狼袭击并杀死的机率还要小。
分支引用
指明一次提交的最直接的方法要求有一个指向它的分支引用。这样，你就可以在任何需要一个提交对象或者
SHA-1 值的 Git 命令中使用该分支名称了。如果你想要显示一个分支的最后一次提交的对象，例如假设topic1
分支指向 ca82a6d，那么下面的命令是等价的：
$ git show ca82a6dff817ec66f44342007202690a93763949 $ git show topic1 |
如果你想知道某个分支指向哪个特定的 SHA，或者想看任何一个例子中被简写的
SHA-1，你可以使用一个叫做 rev-parse 的 Git 探测工具。在第 9 章你可以看到关于探测工具的更多信息；简单来说，rev-parse
是为了底层操作而不是日常操作设计的。不过，有时你想看 Git 现在到底处于什么状态时，它可能会很有用。这里你可以对你的分支运执行rev-parse。
$ git rev-parse topic1 ca82a6dff817ec66f44342007202690a93763949 |
引用日志里的简称
在你工作的同时，Git 在后台的工作之一就是保存一份引用日志——一份记录最近几个月你的
HEAD 和分支引用的日志。
你可以使用 git reflog 来查看引用日志：
$ git reflog 734713b... HEAD@{0}: commit: fixed refs handling, added gc auto,
updated d921970... HEAD@{1}: merge phedders/rdo |
每次你的分支顶端因为某些原因被修改时，Git 就会为你将信息保存在这个临时历史记录里面。你也可以使用这份数据来指明更早的分支。如果你想查看仓库中
HEAD 在五次前的值，你可以使用引用日志的输出中的@{n} 引用：
你也可以使用这个语法来查看一定时间前分支指向哪里。例如，想看你的 master
分支昨天在哪，你可以输入
$ git show master@{yesterday} |
它就会显示昨天分支的顶端在哪。这项技术只对还在你引用日志里的数据有用，所以不能用来查看比几个月前还早的提交。
想要看类似于 git log 输出格式的引用日志信息，你可以运行 git log -g：
$ git log -g master commit 734713bc047d87bf7eac9674765ae793478c50d3 Reflog:
master@{0} (Scott Chacon <schacon@gmail.com>) Re |
需要注意的是，日志引用信息只存在于本地——这是一个你在仓库里做过什么的日志。其他人的仓库拷贝里的引用和你的相同；而你新克隆一个仓库的时候，引用日志是空的，因为你在仓库里还没有操作。只有你克隆了一个项目至少两个月，git
show HEAD@{2.months.ago} 才会有用——如果你是五分钟前克隆的仓库，将不会有结果返回。
祖先引用
另一种指明某次提交的常用方法是通过它的祖先。如果你在引用最后加上一个 ^，Git
将其理解为此次提交的父提交。 假设你的工程历史是这样的：
$ git log --pretty=format:'%h %s' --graph * 734713b fixed refs handling, added gc auto, updated tests * d921970 Merge commit |
那么，想看上一次提交，你可以使用 HEAD^，意思是“HEAD 的父提交”：
$ git show HEAD^ commit d921970aadf03b3cf0e71becdaab3147ba71cdef Merge:
1c002dd... 35cfb2b... Author: Scott Chacon <schacon@ |
你也可以在 ^ 后添加一个数字——例如，d921970^2 意思是“d921970
的第二父提交”。这种语法只在合并提交时有用，因为合并提交可能有多个父提交。第一父提交是你合并时所在分支，而第二父提交是你所合并的分支：
$ git show d921970^ commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b Author:
Scott Chacon <schacon@gmail.com> Date: Thu Dec 1 |
另外一个指明祖先提交的方法是 ~。这也是指向第一父提交，所以 HEAD~
和 HEAD^ 是等价的。当你指定数字的时候就明显不一样了。HEAD~2 是指“第一父提交的第一父提交”，也就是“祖父提交”——它会根据你指定的次数检索第一父提交。例如，在上面列出的历史记录里面，HEAD~3
会是
$ git show HEAD~3 commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d Author:
Tom Preston-Werner <tom@mojombo.com> Date: Fri Nov |
也可以写成 HEAD^^^，同样是第一父提交的第一父提交的第一父提交：
$ git show HEAD^^^ commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d Author:
Tom Preston-Werner <tom@mojombo.com> Date: Fri Nov |
你也可以混合使用这些语法——你可以通过 HEAD~3^2 指明先前引用的第二父提交（假设它是一个合并提交）。
提交范围
现在你已经可以指明单次的提交，让我们来看看怎样指明一定范围的提交。这在你管理分支的时候尤显重要——如果你有很多分支，你可以指明范围来圈定一些问题的答案，比如：“这个分支上我有哪些工作还没合并到主分支的？”
双点
最常用的指明范围的方法是双点的语法。这种语法主要是让 Git 区分出可从一个分支中获得而不能从另一个分支中获得的提交。例如，假设你有类似于图
6-1 的提交历史。
图 6-1. 范围选择的提交历史实例
你想要查看你的试验分支上哪些没有被提交到主分支，那么你就可以使用 master..experiment
来让 Git 显示这些提交的日志——这句话的意思是“所有可从experiment分支中获得而不能从master分支中获得的提交”。为了使例子简单明了，我使用了图标中提交对象的字母来代替真实日志的输出，所以会显示：
$ git log master..experiment D C |
另一方面，如果你想看相反的——所有在 master 而不在 experiment
中的分支——你可以交换分支的名字。experiment..master 显示所有可在master 获得而在
experiment 中不能的提交：
$ git log experiment..master F E |
这在你想保持 experiment 分支最新和预览你将合并的提交的时候特别有用。这个语法的另一种常见用途是查看你将把什么推送到远程：
$ git log origin/master..HEAD |
这条命令显示任何在你当前分支上而不在远程origin 上的提交。如果你运行
git push 并且的你的当前分支正在跟踪origin/master，被git log origin/master..HEAD
列出的提交就是将被传输到服务器上的提交。 你也可以留空语法中的一边来让 Git 来假定它是 HEAD。例如，输入git
log origin/master.. 将得到和上面的例子一样的结果—— Git 使用 HEAD 来代替不存在的一边。
多点
双点语法就像速记一样有用；但是你也许会想针对两个以上的分支来指明修订版本，比如查看哪些提交被包含在某些分支中的一个，但是不在你当前的分支上。Git允许你在引用前使用^字符或者--not指明你不希望提交被包含其中的分支。因此下面三个命令是等同的：
$ git log refA..refB $ git log ^refA refB $ git log refB --not refA |
这样很好，因为它允许你在查询中指定多于两个的引用，而这是双点语法所做不到的。例如，如果你想查找所有从refA或refB包含的但是不被refC包含的提交，你可以输入下面中的一个
$ git log refA refB ^refC $ git log refA refB --not refC |
这建立了一个非常强大的修订版本查询系统，应该可以帮助你解决分支里包含了什么这个问题。
三点
最后一种主要的范围选择语法是三点语法，这个可以指定被两个引用中的一个包含但又不被两者同时包含的分支。回过头来看一下图6-1里所列的提交历史的例子。
如果你想查看master或者experiment中包含的但不是两者共有的引用，你可以运行
$ git log master...experiment F E D C |
这个再次给出你普通的log输出但是只显示那四次提交的信息，按照传统的提交日期排列。
这种情形下，log命令的一个常用参数是--left-right，它会显示每个提交到底处于哪一侧的分支。这使得数据更加有用。
$ git log --left-right master...experiment < F < E > D > C |
有了以上工具，让Git知道你要察看哪些提交就容易得多了。
6.2 交互式暂存
Git提供了很多脚本来辅助某些命令行任务。这里，你将看到一些交互式命令，它们帮助你方便地构建只包含特定组合和部分文件的提交。在你修改了一大批文件然后决定将这些变更分布在几个各有侧重的提交而不是单个又大又乱的提交时，这些工具非常有用。用这种方法，你可以确保你的提交在逻辑上划分为相应的变更集，以便于供和你一起工作的开发者审阅。如果你运行git
add时加上-i或者--interactive选项，Git就进入了一个交互式的shell模式，显示一些类似于下面的信息：
$ git add -i staged unstaged path 1: unchanged +0/-1 TODO 2: unchanged +1/-1 index.html 3: unchanged +5/-1 lib/simplegit.rb |
你会看到这个命令以一个完全不同的视图显示了你的暂存区——主要是你通过git
status得到的那些信息但是稍微简洁但信息更加丰富一些。它在左侧列出了你暂存的变更，在右侧列出了未被暂存的变更。
在这之后是一个命令区。这里你可以做很多事情，包括暂存文件，撤回文件，暂存部分文件，加入未被追踪的文件，查看暂存文件的差别。
暂存和撤回文件
如果你在What now>的提示后输入2或者u，这个脚本会提示你那些文件你想要暂存：
What now> 2 staged unstaged path 1: unchanged +0/-1 TODO 2:
unchanged +1/-1 index.html 3: unchanged +5/-1 lib/simplegit.rb U |
如果想暂存TODO和index.html，你可以输入相应的编号：
Update>> 1,2 staged unstaged path * 1: unchanged +0/-1 TODO * 2:
unchanged +1/-1 index.html 3: unchanged +5/-1 lib/simplegit. |
每个文件旁边的*表示选中的文件将被暂存。如果你在update>>提示后直接敲入回车，Git会替你把所有选中的内容暂存：
Update>> updated 2 paths *** Commands *** 1: status 2: update 3:
revert 4: add untracked 5: patch 6: diff 7: quit 8: help Wha |
现在你可以看到TODO和index.html文件被暂存了同时simplegit.rb文件仍然未被暂存。如果这时你想要撤回TODO文件，就使用3或者r（代表revert，恢复）选项：
*** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> 3 staged unstaged |
再次查看Git的状态，你会看到你已经撤回了TODO文件
*** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> 1 staged unstaged |
要查看你暂存内容的差异，你可以使用6或者d（表示diff）命令。它会显示你暂存文件的列表，你可以选择其中的几个，显示其被暂存的差异。这跟你在命令行下指定git
diff --cached非常相似：
*** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> 6 staged unstaged p |
通过这些基本命令，你可以使用交互式增加模式更加方便地处理暂存区。
暂存补丁
只让Git暂存文件的某些部分而忽略其他也是有可能的。例如，你对simplegit.rb文件作了两处修改但是只想暂存其中一个而忽略另一个，在Git中实现这一点非常容易。在交互式的提示符下，输入5或者p（表示patch，补丁）。Git会询问哪些文件你希望部分暂存；然后对于被选中文件的每一节，他会逐个显示文件的差异区块并询问你是否希望暂存他们：
diff --git a/lib/simplegit.rb b/lib/simplegit.rb index dd5ecc4..57399e0 100644 --- a/lib/simplegit.rb +++ b/lib/simplegit.rb @ |
此处你有很多选择。输入?可以显示列表：
Stage this hunk [y,n,a,d,/,j,J,g,e,?]? ? y - stage this hunk n - do not stage this hunk a - stage this and all the remaining h |
如果你想暂存各个区块，通常你会输入y或者n，但是暂存特定文件里的全部区块或者暂时跳过对一个区块的处理同样也很有用。如果你暂存了文件的一个部分而保留另外一个部分不被暂存，你的状态输出看起来会是这样：
What now> 1 staged unstaged path 1: unchanged +0/-1 TODO 2: +1/-1 nothing index.html 3: +1/-1 +4/-0 lib/simplegit.rb |
simplegit.rb的状态非常有意思。它显示有几行被暂存了，有几行没有。你部分地暂存了这个文件。在这时，你可以退出交互式脚本然后运行git
commit来提交部分暂存的文件。
最后你也可以不通过交互式增加的模式来实现部分文件暂存——你可以在命令行下通过git
add -p或者git add --patch来启动同样的脚本。
6.3 储藏（Stashing）
经常有这样的事情发生，当你正在进行项目中某一部分的工作，里面的东西处于一个比较杂乱的状态，而你想转到其他分支上进行一些工作。问题是，你不想提交进行了一半的工作，否则以后你无法回到这个工作点。解决这个问题的办法就是git
stash命令。
“‘储藏”“可以获取你工作目录的中间状态——也就是你修改过的被追踪的文件和暂存的变更——并将它保存到一个未完结变更的堆栈中，随时可以重新应用。
储藏你的工作
为了演示这一功能，你可以进入你的项目，在一些文件上进行工作，有可能还暂存其中一个变更。如果你运行
git status，你可以看到你的中间状态：
$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: index |
现在你想切换分支，但是你还不想提交你正在进行中的工作；所以你储藏这些变更。为了往堆栈推送一个新的储藏，只要运行
git stash：
$ git stash Saved working directory and index state \ "WIP on master: 049d078 added the index file" HEAD is now at 049d078 a |
你的工作目录就干净了：
$ git status # On branch master nothing to commit (working directory clean) |
这时，你可以方便地切换到其他分支工作；你的变更都保存在栈上。要查看现有的储藏，你可以使用
git stash list：
$ git stash list stash@{0}: WIP on master: 049d078 added the index file stash@{1}: WIP on master: c264051... Revert "added f |
在这个案例中，之前已经进行了两次储藏，所以你可以访问到三个不同的储藏。你可以重新应用你刚刚实施的储藏，所采用的命令就是之前在原始的
stash 命令的帮助输出里提示的：git stash apply。如果你想应用更早的储藏，你可以通过名字指定它，像这样：git
stash apply stash@{2}。如果你不指明，Git 默认使用最近的储藏并尝试应用它：
$ git stash apply # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # |
你可以看到 Git 重新修改了你所储藏的那些当时尚未提交的文件。在这个案例里，你尝试应用储藏的工作目录是干净的，并且属于同一分支；但是一个干净的工作目录和应用到相同的分支上并不是应用储藏的必要条件。你可以在其中一个分支上保留一份储藏，随后切换到另外一个分支，再重新应用这些变更。在工作目录里包含已修改和未提交的文件时，你也可以应用储藏——Git
会给出归并冲突如果有任何变更无法干净地被应用。
对文件的变更被重新应用，但是被暂存的文件没有重新被暂存。想那样的话，你必须在运行 git stash
apply 命令时带上一个 --index 的选项来告诉命令重新应用被暂存的变更。如果你是这么做的，你应该已经回到你原来的位置：
$ git stash apply --index # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # mod |
apply 选项只尝试应用储藏的工作——储藏的内容仍然在栈上。要移除它，你可以运行
git stash drop，加上你希望移除的储藏的名字：
$ git stash list stash@{0}: WIP on master: 049d078 added the index file stash@{1}: WIP on master: c264051... Revert "added f |
你也可以运行 git stash pop 来重新应用储藏，同时立刻将其从堆栈中移走。
Un-applying a Stash
In some use case scenarios you might
want to apply stashed changes, do some work, but then
un-apply those changes that originally came form the
stash. Git does not provide such astash unapply command,
but it is possible to achieve the effect by simply retrieving
the patch associated with a stash and applying it in
reverse:
$ git stash show -p stash@{0} | git apply -R |
Again, if you don’t specify a stash, Git assumes the
most recent stash:
$ git stash show -p | git apply -R |
You may want to create an alias and effectively add
a stash-unapply command to your git. For example:
$ git config --global alias.stash-unapply '!git stash show -p | git apply -R' $ git stash $ #... work work work $ git stash- |
从储藏中创建分支
如果你储藏了一些工作，暂时不去理会，然后继续在你储藏工作的分支上工作，你在重新应用工作时可能会碰到一些问题。如果尝试应用的变更是针对一个你那之后修改过的文件，你会碰到一个归并冲突并且必须去化解它。如果你想用更方便的方法来重新检验你储藏的变更，你可以运行git
stash branch，这会创建一个新的分支，检出你储藏工作时的所处的提交，重新应用你的工作，如果成功，将会丢弃储藏。
$ git stash branch testchanges Switched to a new branch "testchanges" # On branch testchanges # Changes to be committed: # ( |
这是一个很棒的捷径来恢复储藏的工作然后在新的分支上继续当时的工作。
|
