使用 log、show 和 diff 查看 Git 历史
假设你在周一早上打开 weather-app，却想不起周五发布的是什么。或者一位队友问你为什么上周改了温度转换公式，你想要真实答案而不是猜测。提交循环涵盖了如何保存提交。本章涵盖的是读取历史：发生了什么、谁做的，以及何时发生的。执行这个操作的命令是 git log，以下是它为一个小项目打印的所有内容：
$ git log
commit 4f2a1c9d8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c
Author: 李明 <[email protected]m>
Date: Tue Jul 14 09:12:03 2026 +0100
修复摄氏度到华氏度转换公式中的温度转换错误
commit 5f3d8b21a90e7c6d5b4a3f2e1d0c9b8a7f6e5d4c
Author: 王刚 <[email protected]m>
Date: Mon Jul 13 16:45:22 2026 +0100
在仪表盘中添加五天预报
commit 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b
Author: 王刚 <[email protected]m>
Date: Mon Jul 13 11:03:47 2026 +0100
设置项目结构一条命令，整个项目的故事就摆在眼前：三个提交，最新的在前，每个都显示了谁写的、什么时候写的、以及为什么写的。
使用 git log 读取日志
git log 遍历从你当前位置可以到达的每个提交，最新的首先出现。每条条目显示四件事：一个哈希值（标识该确切提交的长字母数字串）、作者、日期和其作者编写的消息。
一个**提交是将这四件事捆绑在一起：该时刻每个被追踪文件的快照、描述更改的消息、谁做的、以及到它之前那个提交的链接，即它的父提交**。这个父链接是将一堆单独的快照转变为真实时间线的原因。从上到下读 git log 就是从现在向项目开始倒读这条时间线。
哈希值一开始看起来很吓人，但你很少需要整个东西。4f2a1c9d8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c 和 4f2a1c9 指向同一个提交。Git 只需要足够的哈希来把它与仓库中的其他提交区分开，前七八个字符几乎总是足够的。你会在各个地方看到短形式，包括本章剩余部分的命令。
git log 列出每个提交，最新的首先，带有它的哈希、作者、日期和消息。提交是那个快照加上它的消息加上到它之前提交的链接。你几乎从不需要完整的哈希，前几个字符对 Git 来说足以确切地知道你指的是哪个提交。 使用 git show 检查单个提交
git log 告诉你提交发生了。git show <hash> 告诉你它确切做了什么：
$ git show 4f2a1c9
commit 4f2a1c9d8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c
Author: 李明 <[email protected]m>
Date: Tue Jul 14 09:12:03 2026 +0100
修复摄氏度到华氏度转换公式中的温度转换错误
diff --git a/src/index.js b/src/index.js
index 3f2c1a9..7b8e2d4 100644
--- a/src/index.js
+++ b/src/index.js
@@ -12,7 +12,7 @@ function celsiusToFahrenheit(celsius) {
- return celsius * (9 / 5 + 32)
+ return (celsius * 9) / 5 + 32上半部分是 git log 显示的相同元数据。下面是实际的更改：以 - 开头的行是提交删除的行，以 + 开头的行是它添加的行，无标记的行是保持不变的上下文。这里读起来很清楚：旧行把 32 分组在括号内，所以它在乘法之前就被添加了。这个修复重新将括号分组在 celsius * 9 周围，这样 32 最后被添加，就是李明的消息描述的运算符优先级错误。
git show <hash> 完整显示一个提交：谁做的、什么时候做的，以及它更改的实际行。删除的行以减号开头，添加的行以加号开头。这是回答"这个提交实际上做了什么"的最快方式。 git diff 显示什么，以及几乎每个人都会犯的误区
git log 和 git show 读取已提交的历史。git diff 读取尚未提交的内容：现在坐在你工作目录中、与你最后一次提交相比的更改。
$ git diff
diff --git a/README.md b/README.md
index 1c2d3e4..9f8a7b6 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
# weather-app
+用原生 JavaScript 构建的五天天气仪表盘。这是你对 README.md 所做的编辑，在你暂存或提交任何东西之前显示。这里是让几乎每个人在第一周陷入困境的部分：运行 git add . 来暂存相同的更改，然后再运行 git diff，它什么都不显示。
$ git add .
$ git diff什么都没有打印。编辑没有消失，也没有什么地方出错。普通的 git diff 比较你的工作目录与暂存区，一旦你暂存了所有东西，这两个现在匹配，所以那里没有左差异了。要查看等待在暂存区中的更改，改用 git diff --staged。
$ git diff --staged
diff --git a/README.md b/README.md
index 1c2d3e4..9f8a7b6 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
# weather-app
+用原生 JavaScript 构建的五天天气仪表盘。相同的更改，现在可见，因为 --staged 比较暂存区与你的最后一次提交。
git diff 显示你工作目录中尚未暂存的编辑。一旦你使用 git add 暂存了所有东西，普通的 git diff 就会保持沉默。这是预期的，你的更改仍在那里。使用 git diff --staged 来查看等待提交的内容。 为什么 Git 历史形成一个图
你到目前为止看到的每个提交都指向确切的一个父提交，从上到下读 git log 感觉像在读一条直线。这对于在单一工作线上进行的单独项目是成立的。一旦分支和合并出现，这就停止成立了，下一章的分支中涵盖，因为项目的真实历史可以分裂成单独的线并重新汇合。