2.2 Git基础 | 我没有找到她的脑袋

type

status

date

slug

summary

查看提交历史

在提交了若干更新，又或者克隆了某个项目之后，你也许想回顾下提交历史。完成这个任务最简单而又有效的工具是 git log 命令。

我们使用一个非常简单的 “simplegit” 项目作为示例。运行下面的命令获取该项目：

当你在此项目中运行 git log 命令时，可以看到下面的输出：

不传入任何参数的默认情况下，git log 会按时间先后顺序列出所有的提交，最近的更新排在最上面。正如你所看到的，这个命令会列出每个提交的 SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明。

git log 有许多选项可以帮助你搜寻你所要找的提交，下面我们会介绍几个最常用的选项。

其中一个比较有用的选项是 -p 或 --patch ，它会显示每次提交所引入的差异（按补丁的格式输出）。你也可以限制显示的日志条目数量，例如使用 -2 选项来只显示最近的两次提交：

该选项除了显示基本信息之外，还附带了每次提交的变化。当进行代码审查，或者快速浏览某个搭档的提交所带来的变化的时候，这个参数就非常有用了。 你也可以为 git log 附带一系列的总结性选项。比如你想看到每次提交的简略统计信息，可以使用 --stat 选项：

正如你所看到的，--stat 选项在每次提交的下面列出所有被修改过的文件、有多少文件被修改了以及被修改过的文件的哪些行被移除或是添加了。在每次提交的最后还有一个总结。

另一个非常有用的选项是 --pretty。这个选项可以使用不同于默认格式的方式展示提交历史。这个选项有一些内建的子选项供你使用。比如 oneline 会将每个提交放在一行显示，在浏览大量的提交时非常有用。另外还有 short，full 和 fuller 选项，它们展示信息的格式基本一致，但是详尽程度不一：

最有意思的是 format ，可以定制记录的显示格式。这样的输出对后期提取分析格外有用——因为你知道输出的格式不会随着 Git 的更新而发生改变：

git log --pretty=format 常用的选项列出了 format 接受的常用格式占位符的写法及其代表的意义。

选项	说明
`%H`	提交的完整哈希值
`%h`	提交的简写哈希值
`%T`	树的完整哈希值
`%t`	树的简写哈希值
`%P`	父提交的完整哈希值
`%p`	父提交的简写哈希值
`%an`	作者名字
`%ae`	作者的电子邮件地址
`%ad`	作者修订日期（可以用 --date=选项来定制格式）
`%ar`	作者修订日期，按多久以前的方式显示
`%cn`	提交者的名字
`%ce`	提交者的电子邮件地址
`%cd`	提交日期
`%cr`	提交日期（距今多长时间）
`%s`	提交说明

你一定奇怪 作者和 提交者 之间究竟有何差别，其实作者指的是实际作出修改的人，提交者指的是最后将此工作成果提交到仓库的人。所以，当你为某个项目发布补丁，然后某个核心成员将你的补丁并入项目时，你就是作者，而那个核心成员就是提交者。我们会在 分布式 Git 再详细介绍两者之间的细微差别。

当 oneline 或 format 与另一个 log 选项 --graph 结合使用时尤其有用。这个选项添加了一些 ASCII 字符串来形象地展示你的分支、合并历史：

这种输出类型会在我们下一章学完分支与合并以后变得更加有趣。

以上只是简单介绍了一些 git log 命令支持的选项。 git log 的常用选项列出了我们目前涉及到的和没涉及到的选项，以及它们是如何影响 log 命令的输出的：

选项	说明
`-p`	按补丁格式显示每个提交引入的差异。
`--stat`	显示每次提交的文件修改统计信息。
`--shortstat`	只显示 --stat 中最后的行数修改添加移除统计。
`--name-only`	仅在提交信息后显示已修改的文件清单。
`--name-status`	显示新增、修改、删除的文件清单。
`--abbrev-commit`	仅显示 SHA-1 校验和所有 40 个字符中的前几个字符。
`--relative-date`	使用较短的相对时间而不是完整格式显示日期（比如“2 weeks ago”）。
`--graph`	在日志旁以 ASCII 图形显示分支与合并历史。
`--pretty`	使用其他格式显示历史提交信息。可用的选项包括 oneline、short、full、fuller 和 format（用来定义自己的格式）。
`--oneline`	`--pretty=oneline --abbrev-commit` 合用的简写。

限制输出长度

除了定制输出格式的选项之外，git log 还有许多非常实用的限制输出长度的选项，也就是只输出一部分的提交。之前你已经看到过 -2 选项了，它只会显示最近的两条提交，实际上，你可以使用类似 -<n> 的选项，其中的 n 可以是任何整数，表示仅显示最近的 n 条提交。不过实践中这个选项不是很常用，因为 Git 默认会将所有的输出传送到分页程序中，所以你一次只会看到一页的内容。

但是，类似 --since 和 --until 这种按照时间作限制的选项很有用。例如，下面的命令会列出最近两周的所有提交：

该命令可用的格式十分丰富——可以是类似 "2008-01-15" 的具体的某一天，也可以是类似 "2 years 1 day 3 minutes ago" 的相对日期。

还可以过滤出匹配指定条件的提交。用 --author 选项显示指定作者的提交，用 --grep 选项搜索提交说明中的关键字。

Note	你可以指定多个 `--author` 和 `--grep` 搜索条件，这样会只输出匹配任意 `--author` 模式和任意 `--grep` 模式的提交。然而，如果你添加了 `--all-match` 选项，则只会输出匹配所有 `--grep` 模式的提交。
ㅤ	ㅤ

另一个非常有用的过滤器是 -S（俗称“pickaxe”选项，取“用鹤嘴锄在土里捡石头”之意），它接受一个字符串参数，并且只会显示那些添加或删除了该字符串的提交。假设你想找出添加或删除了对某一个特定函数的引用的提交，可以调用：

最后一个很实用的 git log 选项是路径（path），如果只关心某些文件或者目录的历史提交，可以在 git log 选项的最后指定它们的路径。因为是放在最后位置上的选项，所以用两个短划线（--）隔开之前的选项和后面限定的路径名。

在限制 git log 输出的选项中列出了常用的选项

选项	说明
`-<n>`	仅显示最近的 n 条提交。
`--since`, `--after`	仅显示指定时间之后的提交。
`--until`, `--before`	仅显示指定时间之前的提交。
`--author`	仅显示作者匹配指定字符串的提交。
`--committer`	仅显示提交者匹配指定字符串的提交。
`--grep`	仅显示提交说明中包含指定字符串的提交。
`-S`	仅显示添加或删除内容匹配指定字符串的提交。

来看一个实际的例子，如果要在 Git 源码库中查看 Junio Hamano 在 2008 年 10 月其间，除了合并提交之外的哪一个提交修改了测试文件，可以使用下面的命令：

在近 40000 条提交中，上面的输出仅列出了符合条件的 6 条记录。

Tip	隐藏合并提交按照你代码仓库的工作流程，记录中可能有为数不少的合并提交，它们所包含的信息通常并不多
ㅤ	ㅤ

撤消操作

在任何一个阶段，你都有可能想要撤消某些操作。我们将会学习几个撤消你所做修改的基本工具。 注意，有些撤消操作是不可逆的。这是在使用 Git 的过程中，会因为操作失误而导致之前的工作丢失的少有的几个地方之一。

有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了。此时，可以运行带有 --amend 选项的提交命令来重新提交：

这个命令会将暂存区中的文件提交。如果自上次提交以来你还未做任何修改（例如，在上次提交后马上执行了此命令），那么快照会保持不变，而你所修改的只是提交信息。

文本编辑器启动后，可以看到之前的提交信息。编辑后保存会覆盖原来的提交信息。

例如，你提交后发现忘记了暂存某些需要的修改，可以像下面这样操作：

最终你只会有一个提交——第二次提交将代替第一次提交的结果。

Note

当你在修补最后的提交时，与其说是修复旧提交，倒不如说是完全用一个 新的提交 替换旧的提交，理解这一点非常重要。从效果上来说，就像是旧有的提交从未存在过一样，它并不会出现在仓库的历史中。修补提交最明显的价值是可以稍微改进你最后的提交，而不会让“啊，忘了添加一个文件”或者 “小修补，修正笔误”这种提交信息弄乱你的仓库历史。

ㅤ

取消暂存的文件

接下来的两个小节演示如何操作暂存区和工作目录中已修改的文件。这些命令在修改文件状态的同时，也会提示如何撤消操作。例如，你已经修改了两个文件并且想要将它们作为两次独立的修改提交，但是却意外地输入 git add * 暂存了它们两个。如何只取消暂存两个中的一个呢？ git status 命令提示了你：

在 “Changes to be committed” 文字正下方，提示使用 git reset HEAD <file>... 来取消暂存。所以，我们可以这样来取消暂存 CONTRIBUTING.md 文件：

这个命令有点儿奇怪，但是起作用了。 CONTRIBUTING.md 文件已经是修改未暂存的状态了。

Note	`git reset` 确实是个危险的命令，如果加上了 `--hard` 选项则更是如此。然而在上述场景中，工作目录中的文件尚未修改，因此相对安全一些。
ㅤ	ㅤ

到目前为止这个神奇的调用就是你需要对 git reset 命令了解的全部。我们将会在重置揭密中了解 reset 的更多细节以及如何掌握它做一些真正有趣的事。

撤消对文件的修改

如果你并不想保留对 CONTRIBUTING.md 文件的修改怎么办？你该如何方便地撤消修改——将它还原成上次提交时的样子（或者刚克隆完的样子，或者刚把它放入工作目录时的样子）？幸运的是，git status 也告诉了你应该如何做。在最后一个例子中，未暂存区域是这样：

它非常清楚地告诉了你如何撤消之前所做的修改。让我们来按照提示执行：

可以看到那些修改已经被撤消了。

Important

请务必记得 git checkout -- <file> 是一个危险的命令。你对那个文件在本地的任何修改都会消失——Git 会用最近提交的版本覆盖掉它。除非你确实清楚不想要对那个文件的本地修改了，否则请不要使用这个命令。

如果你仍然想保留对那个文件做出的修改，但是现在仍然需要撤消，我们将会在 Git 分支介绍保存进度与分支，这通常是更好的做法。

记住，在 Git 中任何 已提交 的东西几乎总是可以恢复的。甚至那些被删除的分支中的提交或使用 --amend 选项覆盖的提交也可以恢复（阅读数据恢复了解数据恢复）。然而，任何你未提交的东西丢失后很可能再也找不到了。

远程仓库的使用

为了能在任意 Git 项目上协作，你需要知道如何管理自己的远程仓库。远程仓库是指托管在因特网或其他网络中的你的项目的版本库。你可以有好几个远程仓库，通常有些仓库对你只读，有些则可以读写。与他人协作涉及管理远程仓库以及根据需要推送或拉取数据。管理远程仓库包括了解如何添加远程仓库、移除无效的远程仓库、管理不同的远程分支并定义它们是否被跟踪等等。在本节中，我们将介绍一部分远程管理的技能。

Note	远程仓库可以在你的本地主机上你完全可以在一个“远程”仓库上工作，而实际上它在你本地的主机上。词语“远程”未必表示仓库在网络或互联网上的其它位置，而只是表示它在别处。在这样的远程仓库上工作，仍然需要和其它远程仓库上一样的标准推送、拉取和抓取操作。

查看远程仓库

如果想查看你已经配置的远程仓库服务器，可以运行 git remote 命令。它会列出你指定的每一个远程服务器的简写。如果你已经克隆了自己的仓库，那么至少应该能看到 origin ——这是 Git 给你克隆的仓库服务器的默认名字：

你也可以指定选项 -v，会显示需要读写远程仓库使用的 Git 保存的简写与其对应的 URL。

如果你的远程仓库不止一个，该命令会将它们全部列出。例如，与几个协作者合作的，拥有多个远程仓库的仓库看起来像下面这样：

这表示我们能非常方便地拉取其它用户的贡献。我们还可以拥有向他们推送的权限，这里暂不详述。

注意这些远程仓库使用了不同的协议。我们将会在在服务器上搭建 Git 中了解关于它们的更多信息。

添加远程仓库

我们在之前的章节中已经提到并展示了 git clone 命令是如何自行添加远程仓库的，不过这里将告诉你如何自己来添加它。运行 git remote add <shortname> <url> 添加一个新的远程 Git 仓库，同时指定一个方便使用的简写：

现在你可以在命令行中使用字符串 pb 来代替整个 URL。例如，如果你想拉取 Paul 的仓库中有但你没有的信息，可以运行 git fetch pb：

现在 Paul 的 master 分支可以在本地通过 pb/master 访问到——你可以将它合并到自己的某个分支中，或者如果你想要查看它的话，可以检出一个指向该点的本地分支。（我们将会在 Git 分支中详细介绍什么是分支以及如何使用分支。）

从远程仓库中抓取与拉取

就如刚才所见，从远程仓库中获得数据，可以执行：

这个命令会访问远程仓库，从中拉取所有你还没有的数据。执行完成后，你将会拥有那个远程仓库中所有分支的引用，可以随时合并或查看。

如果你使用 clone 命令克隆了一个仓库，命令会自动将其添加为远程仓库并默认以 “origin” 为简写。所以，git fetch origin 会抓取克隆（或上一次抓取）后新推送的所有工作。必须注意 git fetch 命令只会将数据下载到你的本地仓库——它并不会自动合并或修改你当前的工作。当准备好时你必须手动将其合并入你的工作。

如果你的当前分支设置了跟踪远程分支（阅读下一节和 Git 分支了解更多信息），那么可以用 git pull 命令来自动抓取后合并该远程分支到当前分支。这或许是个更加简单舒服的工作流程。默认情况下，git clone 命令会自动设置本地 master 分支跟踪克隆的远程仓库的 master 分支（或其它名字的默认分支）。运行 git pull 通常会从最初克隆的服务器上抓取数据并自动尝试合并到当前所在的分支。

推送到远程仓库

当你想分享你的项目时，必须将其推送到上游。这个命令很简单：git push <remote> <branch>。当你想要将 master 分支推送到 origin 服务器时（再次说明，克隆时通常会自动帮你设置好那两个名字）， 那么运行这个命令就可以将你所做的备份到服务器：

只有当你有所克隆服务器的写入权限，并且之前没有人推送过时，这条命令才能生效。当你和其他人在同一时间克隆，他们先推送到上游然后你再推送到上游，你的推送就会毫无疑问地被拒绝。你必须先抓取他们的工作并将其合并进你的工作后才能推送。阅读 Git 分支了解如何推送到远程仓库服务器的详细信息。

查看某个远程仓库

如果想要查看某一个远程仓库的更多信息，可以使用 git remote show <remote> 命令。如果想以一个特定的缩写名运行这个命令，例如 origin，会得到像下面类似的信息：

它同样会列出远程仓库的 URL 与跟踪分支的信息。这些信息非常有用，它告诉你正处于 master 分支，并且如果运行 git pull，就会抓取所有的远程引用，然后将远程 master 分支合并到本地 master 分支。它也会列出拉取到的所有远程引用。

这是一个经常遇到的简单例子。如果你是 Git 的重度使用者，那么还可以通过 git remote show 看到更多的信息。

这个命令列出了当你在特定的分支上执行 git push 会自动地推送到哪一个远程分支。它也同样地列出了哪些远程分支不在你的本地，哪些远程分支已经从服务器上移除了，还有当你执行 git pull 时哪些本地分支可以与它跟踪的远程分支自动合并。

远程仓库的重命名与移除

你可以运行 git remote rename 来修改一个远程仓库的简写名。例如，想要将 pb 重命名为 paul，可以用 git remote rename 这样做：

值得注意的是这同样也会修改你所有远程跟踪的分支名字。那些过去引用 pb/master 的现在会引用 paul/master。

如果因为一些原因想要移除一个远程仓库——你已经从服务器上搬走了或不再想使用某一个特定的镜像了，又或者某一个贡献者不再贡献了——可以使用 git remote remove 或 git remote rm ：

一旦你使用这种方式删除了一个远程仓库，那么所有和这个远程仓库相关的远程跟踪分支以及配置信息也会一起被删除。

打标签

像其他版本控制系统（VCS）一样，Git 可以给仓库历史中的某一个提交打上标签，以示重要。比较有代表性的是人们会使用这个功能来标记发布结点（ v1.0 、 v2.0 等等）。在本节中，你将会学习如何列出已有的标签、如何创建和删除新的标签、以及不同类型的标签分别是什么。

列出标签

在 Git 中列出已有的标签非常简单，只需要输入 git tag （可带上可选的 -l 选项 --list）：

这个命令以字母顺序列出标签，但是它们显示的顺序并不重要。

你也可以按照特定的模式查找标签。例如，Git 自身的源代码仓库包含标签的数量超过 500 个。如果只对 1.8.5 系列感兴趣，可以运行：

Note	按照通配符列出标签需要 `-l` 或 `--list` 选项如果你只想要完整的标签列表，那么运行 `git tag` 就会默认假定你想要一个列表，它会直接给你列出来，此时的 `-l` 或 `--list` 是可选的。然而，如果你提供了一个匹配标签名的通配模式，那么 `-l` 或 `--list` 就是强制使用的。

创建标签

Git 支持两种标签：轻量标签（lightweight）与附注标签（annotated）。

轻量标签很像一个不会改变的分支——它只是某个特定提交的引用。

而附注标签是存储在 Git 数据库中的一个完整对象，它们是可以被校验的，其中包含打标签者的名字、电子邮件地址、日期时间，此外还有一个标签信息，并且可以使用 GNU Privacy Guard （GPG）签名并验证。通常会建议创建附注标签，这样你可以拥有以上所有信息。但是如果你只是想用一个临时的标签，或者因为某些原因不想要保存这些信息，那么也可以用轻量标签。

附注标签

在 Git 中创建附注标签十分简单。最简单的方式是当你在运行 tag 命令时指定 -a 选项：

m 选项指定了一条将会存储在标签中的信息。如果没有为附注标签指定一条信息，Git 会启动编辑器要求你输入信息。

通过使用 git show 命令可以看到标签信息和与之对应的提交信息：

输出显示了打标签者的信息、打标签的日期时间、附注信息，然后显示具体的提交信息。

轻量标签

另一种给提交打标签的方式是使用轻量标签。轻量标签本质上是将提交校验和存储到一个文件中——没有保存任何其他信息。创建轻量标签，不需要使用 -a、-s 或 -m 选项，只需要提供标签名字：

这时，如果在标签上运行 git show，你不会看到额外的标签信息。命令只会显示出提交信息：

后期打标签

你也可以对过去的提交打标签。假设提交历史是这样的：

现在，假设在 v1.2 时你忘记给项目打标签，也就是在 “updated rakefile” 提交。你可以在之后补上标签。要在那个提交上打标签，你需要在命令的末尾指定提交的校验和（或部分校验和）：

可以看到你已经在那次提交上打上标签了：

共享标签

默认情况下，git push 命令并不会传送标签到远程仓库服务器上。在创建完标签后你必须显式地推送标签到共享服务器上。这个过程就像共享远程分支一样——你可以运行 git push origin <tagname>。

如果想要一次性推送很多标签，也可以使用带有 --tags 选项的 git push 命令。这将会把所有不在远程仓库服务器上的标签全部传送到那里。

现在，当其他人从仓库中克隆或拉取，他们也能得到你的那些标签。

Note	`git push` 推送两种标签使用 `git push <remote> --tags` 推送标签并不会区分轻量标签和附注标签，没有简单的选项能够让你只选择推送一种标签。

删除标签

要删除掉你本地仓库上的标签，可以使用命令 git tag -d <tagname>。例如，可以使用以下命令删除一个轻量标签：

注意上述命令并不会从任何远程仓库中移除这个标签，你必须用 git push <remote> :refs/tags/<tagname> 来更新你的远程仓库：

第一种变体是 git push <remote> :refs/tags/<tagname> ：

上面这种操作的含义是，将冒号前面的空值推送到远程标签名，从而高效地删除它。

第二种更直观的删除远程标签的方式是：

检出标签

如果你想查看某个标签所指向的文件版本，可以使用 git checkout 命令，虽然这会使你的仓库处于“分离头指针（detached HEAD）”的状态——这个状态有些不好的副作用：

在“分离头指针”状态下，如果你做了某些更改然后提交它们，标签不会发生变化，但你的新提交将不属于任何分支，并且将无法访问，除非通过确切的提交哈希才能访问。因此，如果你需要进行更改，比如你要修复旧版本中的错误，那么通常需要创建一个新分支：

如果在这之后又进行了一次提交，version2 分支就会因为这个改动向前移动，此时它就会和 v2.0.0 标签稍微有些不同，这时就要当心了。

Git 别名

在我们结束本章 Git 基础之前，正好有一个小技巧可以使你的 Git 体验更简单、容易、熟悉：别名。我们不会在之后的章节中引用到或假定你使用过它们，但是你大概应该知道如何使用它们。

Git 并不会在你输入部分命令时自动推断出你想要的命令。如果不想每次都输入完整的 Git 命令，可以通过 git config 文件来轻松地为每一个命令设置一个别名。这里有一些例子你可以试试：

这意味着，当要输入 git commit 时，只需要输入 git ci。随着你继续不断地使用 Git，可能也会经常使用其他命令，所以创建别名时不要犹豫。

在创建你认为应该存在的命令时这个技术会很有用。例如，为了解决取消暂存文件的易用性问题，可以向 Git 中添加你自己的取消暂存别名：

这会使下面的两个命令等价：

这样看起来更清楚一些。通常也会添加一个 last 命令，像这样：

这样，可以轻松地看到最后一次提交：

可以看出，Git 只是简单地将别名替换为对应的命令。然而，你可能想要执行外部命令，而不是一个 Git 子命令。如果是那样的话，可以在命令前面加入 ! 符号。如果你自己要写一些与 Git 仓库协作的工具的话，那会很有用。我们现在演示将 git visual 定义为 gitk 的别名：