git reset 命令详解（二）

上一篇博文git reset 命令详解（一）讲了 git reset 命令的基本原理和用法，这篇博文谈一谈 git reset 的另一种用法——后面跟一个路径（或文件）。

恢复索引中的文件到某个版本

假设版本库中是文件file.txt的V1版本，HEAD、Index和工作目录都和版本库一致。这时候修改了file.txt文件，并把它（V2版本）加入Index。如下图所示：

现在，运行 git reset file.txt （这其实是 git reset --mixed HEAD file.txt 的简写形式），它会让索引看起来像 HEAD，所以它本质上只是将 file.txt 从 HEAD 复制到索引中。如下图：

仔细对比这两幅图，你会发现 git reset file.txt 有 “取消暂存文件” 的实际效果。它和 git add 所做的事相反。这就是为什么 git status 命令的输出会建议运行此命令来取消暂存一个文件。例如：

$ git add *
$ git status
On branch master
Changes to be committed:(use "git reset HEAD <file>..." to unstage)renamed:    README.md -> READMEmodified:   CONTRIBUTING.md

另外，我们可以不让 Git 从 HEAD 拉取数据，而是通过具体指定一个提交来拉取该文件的对应版本。我们只需运行类似于 git reset eb43bf file.txt 的命令即可。依然用图来说明：

以上是版本库、Index 和工作目录的状态。

现在，执行git reset eb43 file.txt

压缩提交（squashing commit）

假设你有一个项目，第一次提交中增加了文件 a，第二次提交增加了一个新的文件 b 并修改了 a，第三次提交再次修改了 a。如下图：

你发现第二次和第三次提交其实是增加了一个软件功能，把二者压缩成一次提交更合理。那么可以这样做：

首先，运行 git reset --soft HEAD~2 来将 HEAD 分支移动到一个旧一点的提交上（即你想要保留的最近一次提交）：

然后，运行 git commit

现在你可以查看可到达的历史，即将会推送的历史，现在看起来有个 v1 版 file-a.txt 的提交，接着第二个提交将 file-a.txt 修改成了 v3 版并增加了 file-b.txt。包含 v2 版本的文件已经不在历史中了。

参考资料

《Pro Git》（Scott Chacon, Ben Straub Version 2.1.14, 2018-05-19）