山海尽明意刚接触 Git 的时候，我总觉得查提交记录就得用 git log，然后直接一敲，满屏输出直接把终端刷穿。真正开始管理项目才发现，git log 只是起点，真正高频的需求往往是"这个文件到底被谁改过、为什么改、改动内容是什么"。尤其是代码评审、线上问题回溯、交接别人写了一半的模块时，盯着一个文件问"它经历过什么"是最常见的场景。
这篇文章就围绕"查看某个文件 Git 提交记录的两种方法"来写。第一种是用 git log -- <文件路径> 拿到文件的提交历史列表，适合快速看这个文件的演进脉络；第二种是用 git log -p -- <文件路径> 直接看到每次提交对应的具体 diff，适合追查某一行代码是被哪次提交改掉的。对于刚开始用 Git 或者一直靠 git log 硬扛全文输出的朋友，这两招足够覆盖日常 90% 的文件追溯需求。文末我还会补充几个配合 git blame、--follow、--diff-filter 的进阶场景，以及我在实际排查中踩过的坑，帮你少走弯路。
1. 先搞清楚：这两种方法分别解决什么问题
很多人有个误区，以为查文件提交记录就是用 git log 加个路径参数，其实这么理解太粗糙了。同样是"查看某个文件的 git 提交记录"，在不同场景下，你需要的粒度完全不同。
1.1 快速总览两种方法的差异
我先把两种命令放在一起做个对比，后面再逐个拆开讲。
| 维度 | 方法一 git log -- <file> |
方法二 git log -p -- <file> |
|---|---|---|
| 核心输出 | 提交哈希、作者、日期、提交说明 | 每次提交对应的完整 diff 补丁 |
| 回答的问题 | 这个文件什么时候被改过、改了多少次 | 每次改动究竟改了什么内容、改了几行 |
| 查看速度 | 快，信息量小 | 慢，信息量大，提交多时会刷屏 |
| 典型场景 | 梳理文件演进历史、确认改动频率 | 定位某行代码的变更来源、代码评审 |
| 组合参数 | --oneline、--stat、--pretty 等 |
-w、--word-diff、--follow 等 |
从表格能看出来，方法一适合"看骨架"，方法二适合"看血肉"。实际工作中，我通常是先跑方法一拿到提交列表，再挑其中一个具体的哈希跑方法二看 diff，两步配合使用效率最高。
1.2 怎么判断该用哪一个
判断标准其实很简单：问自己一个问题，你现在是"想知道有过哪些改动"，还是"想知道某次改动改了什么"。
我举个例子。有一次线上反馈日期显示差了一天，我第一反应是这个日期格式化工具函数最近是不是被改过。这时候直接跑 git log --oneline -- src/utils/date-helper.ts，几秒钟就能确认最近三次提交确实都动过这个文件。但具体是哪一行改错的，光看提交说明没用，这时候就得对可疑的提交哈希跑 git show <hash> -- src/utils/date-helper.ts，或者直接用 git log -p -- src/utils/date-helper.ts 一次性把所有改动都看一遍。
简而言之，需要全面历史就选方法一，需要细节 diff 就选方法二。前者是索引，后者是正文，两者没有优劣之分。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 方法一：用 git log 加路径参数查看提交历史
方法一的语法很简单，核心就是在 git log 后面加两个横杠再加文件路径：
bash复制git log -- <文件路径>
这里的 -- 很关键，它是 Git 参数结束的标记，告诉 Git 后面的内容都是文件路径，而不是分支名或者标签名。如果没有这个标记，万一你的文件名刚好和某个分支重名，Git 就会理解错。
2.1 基本用法与输出解读
进入项目仓库后，我经常是这么操作的：
bash复制git log -- src/utils/date-helper.ts
终端输出大概是这个样子：
code复制commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
Author: 张三 <zhangsan@example.com>
Date: Mon Jun 10