GitHub Desktop 怎么查看某次提交前后的行级差异

在 GitHub Desktop 里查看某次提交的前后差异，入口不是当前的“Changes”列表，而是左侧的 History。先确认顶部的 Current Branch，再选中目标提交和文件，右侧就会显示这次提交实际引入的增删行。若改动被空白字符淹没，可切换为 Split、隐藏空白变化，或展开完整文件。

先确认分支，再进入 History

如果你知道提交消息的大致关键词，却在列表里找不到，先看工具栏的 Current Branch。GitHub Desktop 的提交历史按当前分支展示；分支选错时，后面的筛选和点选都不会得到想要的结果。确认分支后，点击左侧 History，也可以使用 macOS 的 Command+2 或 Windows 的 Ctrl+2 打开历史视图。

1. 在顶部确认当前仓库和 Current Branch 的名称。
2. 在左侧点击 History，按提交消息、时间或提交者定位目标记录。
3. 观察提交条目下的文件列表，先不要把它和当前的未提交文件混在一起。

看到提交消息、时间和文件列表，说明入口正确。若只看到刚编辑但还没有提交的文件，应回到 Changes；这两个视图回答的是不同问题。

选提交和文件，打开行级差异

在 History 中点击目标提交。提交包含多个文件时，再点其中一个文件，右侧会切换到该文件的差异区域。这里显示的是该提交带来的变化：新增行通常以绿色标识，删除行以红色标识，未改变的上下文只用于定位。

1. 单击目标提交，先看它的消息和时间是否符合预期。
2. 在提交下方的文件列表中点击要审阅的文件。
3. 沿着行号向上、向下读上下文，确认变化属于这个提交，而不是当前工作区。

如果一次要对照连续提交，可以在 macOS 按住 Command，或在 Windows 按住 Ctrl，再选择多个条目；范围选择适合查看一组紧邻提交的累计变化，但要留意它不再只代表单个提交。

用 Unified、Split 和空白设置读清楚变化

差异区域右上角的设置按钮决定阅读方式。Unified 把旧内容和新内容按一条纵向差异流排列，适合连续阅读；Split 把旧内容放左侧、新内容放右侧，适合逐行核对。若只是格式化导致大量行被标记，可以勾选 Hide Whitespace Changes，但不要据此判断真实代码没有变化。

改动区域上下的箭头可以补出更多上下文；需要完整文件时，在差异区域右键选择 Expand Whole File。这一步只改变阅读范围，不会修改提交内容。

最后用三个信号确认没有看错

因此，最短路径就是“确认 Current Branch → History → 目标提交 → 目标文件”。如果行数太少，再展开上下文或整个文件；如果内容完全对不上，优先回到分支选择，而不是马上怀疑 Git 的提交记录。

常见问题

为什么 History 里没有刚才改过的内容？

因为改动可能还没有提交。回到 Changes 查看本地工作区；History 只展示已经写入提交历史的变化。

为什么打开的是另一个文件的差异？

一个提交可能包含多个文件。重新点提交下方的目标文件，右侧才会切换到对应的行差异。

隐藏空白变化会不会删除代码？

不会。它只是改变差异视图的显示方式，不会修改工作区、提交或文件内容。