企业官网建设流程全解析

1. 为什么 git log 值得单独拎出来讲

很多人用 Git 的日常就是add、commit、push三件套，git log顶多敲一个不带任何参数的裸命令，看到一屏密密麻麻的提交记录就按q退出，然后该干嘛干嘛。我以前也这样，直到有一次线上出了个诡异的 bug，需要定位是哪个提交引入的，我才发现——不会用git log，等于在一堆没有标签的纸箱子里找一个不知道长什么样的东西。

git log是 Git 里最被低估的命令之一。它不只是"看历史"，而是一套完整的历史检索、过滤、对比、追溯工具。你可以用它查某个文件在三个月内被谁改过、查某个关键词是哪次提交引入的、查两个分支分叉之后各自多了哪些提交、甚至用图形化方式看整个分支的合并拓扑。这些能力在排查问题、做代码审查、写变更日志的时候，价值极高。

这篇文章面向所有已经会用 Git 基本操作、但git log还停留在"敲一下看一眼"阶段的开发者。我会从输出格式、过滤条件、检索技巧、图形化展示、自定义格式化几个维度，把git log的常用姿势和踩坑经验一次讲透。看完之后，你至少能做到：想查什么历史，脑子里立刻能拼出对应的命令，而不是靠搜索引擎现查。

2. git log 的默认输出到底在说什么

2.1 一条提交记录的解剖

先别急着上参数，把裸git log的输出看懂是第一步。随便找个项目敲一下，你会看到类似这样的结构：

commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 Author: Zhang San <zhangsan@example.com> Date: Mon Mar 10 14:23:45 2025 +0800 fix: 修复订单金额计算精度丢失问题

这里每一行都有讲究。第一行的commit后面那串 40 位十六进制是SHA-1 哈希值，它是这次提交的全局唯一身份证。你后面所有针对某次提交的操作，都可以用这个哈希来指代。实际使用时不需要写全 40 位，一般取前 7 到 8 位就够了，Git 会自动匹配，只要这个前缀在当前仓库里不冲突。

Author是提交作者，注意它和Committer是两个概念。作者是实际写代码的人，提交者是执行commit操作的人。在 rebase、cherry-pick 这类操作里，两者会不一样。Date默认显示的是作者日期，不是提交日期，这个坑后面会细说。

空行之后缩进的那段是提交信息。Git 的约定是首行作为简短摘要（一般不超过 50 个字符），空一行后写详细说明。git log默认只显示完整信息，但很多格式化选项会只取首行。

2.2 分页器与退出

裸git log的输出会进入分页器（通常是less），这时候你的操作逻辑和看 man 手册一样：空格翻页、b回退、/关键词搜索、q退出。新手最常见的困惑就是"怎么退不出去"，其实按q就行。

如果你不想进分页器，比如要在脚本里处理输出，可以加--no-pager：

git --no-pager log --oneline -5

或者临时把输出重定向到文件。我个人的习惯是，只要提交数量可能超过一屏，就默认让它进分页器，因为滚动查看比刷屏友好得多。

2.3 默认排序与时间线

git log默认按提交时间倒序排列，最新的在最上面。但这里有个容易误解的点：Git 的历史本质是一个有向无环图（DAG），不是一条直线。当存在合并提交时，"时间顺序"和"拓扑顺序"可能不一致。默认情况下 Git 会尽量按时间排，但你可以用--topo-order强制按拓扑顺序（即父提交一定排在子提交之后），用--date-order按提交时间排但保证父在子后。这个区别在看复杂分支历史时才明显，日常单线开发感知不到。

3. 输出格式：从刷屏到一眼看清

3.1 --oneline 与 --pretty 家族

裸git log一条记录占六七行，看十几条就刷屏了。最常用的精简方式是--oneline：

git log --oneline

输出变成这样：

a1b2c3d fix: 修复订单金额计算精度丢失问题 9f8e7d6 feat: 新增优惠券叠加逻辑 5c4b3a2 refactor: 抽离价格计算模块

每行一个提交，前面是短哈希，后面是提交信息首行。这是日常使用频率最高的格式，没有之一。

如果你想要更灵活的控制，用--pretty或--format（两者等价）。Git 内置了几个预设：

--pretty=short在需要看作者但不想看完整信息时很好用。而--pretty=format:才是真正的杀手锏，后面单独讲。

3.2 自定义格式占位符

--pretty=format:"..."允许你用占位符拼出任意格式。常用的占位符：

• %h：短哈希，%H：完整哈希
• %an：作者名，%ae：作者邮箱
• %ad：作者日期，%cd：提交日期（配合--date=控制格式）
• %s：提交信息首行，%b：提交信息正文
• %d：引用名称（分支、标签）
• %n：换行

我平时最常用的一个组合是：

git log --pretty=format:"%h %ad %an %s" --date=short

输出紧凑，包含哈希、日期、作者、摘要，做变更记录或者发给同事看都很合适。--date=short把日期压成2025-03-10这种形式，比默认的一长串可读性好太多。

提示：--date=支持relative（如"3 days ago"）、iso、short、format:自定义等多种取值。做周报时用--date=format:"%Y-%m-%d %H:%M"能精确到分钟。

3.3 颜色与图形化辅助

--graph会在左侧画出提交的拓扑线，配合--oneline使用效果最佳：

git log --oneline --graph --all

--all表示显示所有分支，不只是当前分支。这样你能一眼看到分支从哪里分出去、在哪里合并回来。字符画虽然简陋，但在终端里排查分支关系非常直观。

颜色方面，Git 默认在终端里会给不同元素上色。如果你把输出重定向到文件发现颜色没了，可以加--color=always强制上色。反过来，如果某些环境颜色干扰阅读，用--no-color关掉。

4. 过滤：从海量提交里精准捞出你要的

4.1 按数量与范围限制

最基础的过滤是限制条数：

git log -5

只看最近 5 条。-n和-5等价，--max-count=5也是同样效果。

按范围过滤用..语法。A..B表示"在 B 里但不在 A 里的提交"，也就是 A 之后 B 新增的提交：

git log main..feature

这条命令列出 feature 分支相对于 main 多出来的提交，做代码审查时特别有用。反过来feature..main就是 main 比 feature 多的提交。

还有三个点的A...B，表示"在 A 或 B 里但不同时在两者里"的提交，也就是两个分支分叉后各自独有的提交。这个在对比两个分支差异时用得上。

4.2 按作者、时间、路径过滤

按作者：

git log --author="zhangsan"

支持正则，所以--author="zhang\|li"可以匹配多个作者。注意匹配的是作者名或邮箱，不是提交者。

按时间：

git log --since="2025-03-01" --until="2025-03-31"

--since和--after等价，--until和--before等价。时间格式很灵活，"2 weeks ago"、"yesterday"、"2025-03-01 12:00"都能识别。做月度总结时这个特别省事。

按路径：

git log -- src/utils/price.js

只显示改过这个文件的提交。路径可以跟目录，也可以跟多个路径。这个功能在排查"某个文件什么时候被改坏的"时是首选。

4.3 按提交信息检索

git log --grep="优惠券"

在所有提交信息里搜索包含"优惠券"的提交。默认区分大小写，加-i忽略大小写。--grep支持正则，也支持多个--grep组合（默认是"或"关系，加--all-match变成"与"）。

这里有个高频混淆点：--grep搜的是提交信息，不是代码内容。想搜代码内容得用-S或-G，下面单独说。

4.4 按代码内容检索：-S 与 -G 的区别

这是git log里最容易被忽视但威力最大的功能。

-S"关键词"查找的是增删了包含该关键词的代码的提交。它统计的是某个字符串出现次数的变化，只要某次提交让这个字符串的出现次数变了，就会被匹配。经典的用法是找某个函数是什么时候被引入或删除的：

git log -S"calculateDiscount" --oneline

-G"正则"则是查找diff 内容匹配该正则的提交。区别在于：-S看的是出现次数的增减，-G看的是 diff 里有没有匹配的行。举个例子，如果某次提交只是把一行代码从foo(a)改成foo(b)，-S"foo"不会匹配（因为foo出现次数没变），但-G"foo"会匹配（因为 diff 里有foo这行）。

实际排查时，如果你知道函数名，用-S找它的引入和删除；如果你想找所有涉及某个模式的改动，用-G。两个都可以配合-p直接看 diff。

5. 看 diff：让历史改动无所遁形

5.1 -p 与 --stat 的取舍

-p（等价于--patch）会在每条提交下面直接展开完整的 diff。信息量巨大，但也很占屏。我一般只在明确要看某几条提交的改动时才用，配合-n限制条数：

git log -p -3

--stat则是显示每个文件的改动统计（增删行数），不展开具体内容：

git log --stat -5

输出类似：

src/utils/price.js | 12 ++++++------ src/api/order.js | 3 +++ 2 files changed, 9 insertions(+), 6 deletions(-)

做变更概览时--stat比-p高效得多。我的习惯是先用--stat扫一眼哪些文件动了，再针对可疑的提交单独git show看细节。

5.2 单词级 diff 与空白处理

--word-diff把 diff 粒度从行降到词，适合看文案修改或者长行里的小改动：

git log -p --word-diff -1

默认用[-删除-]{+新增+}的标记，也可以用--word-diff=color用颜色区分。

-w忽略空白改动，-b忽略空白数量变化。这两个在团队里有人用不同缩进风格时特别有用，能过滤掉大量无意义的空白 diff 噪音。

5.3 只看某个文件的改动历史

把路径过滤和-p结合，就是"追踪某个文件的完整演变史"：

git log -p --follow -- src/utils/price.js

--follow的作用是跟踪文件重命名。如果不加，文件改名之后的历史就断了，只能看到改名后的提交。加上之后 Git 会尝试识别重命名并串起完整历史。这个选项在排查老代码时是救命的，但要注意它只对单个文件生效，不能跟多个路径一起用。

6. 图形化与分支拓扑

6.1 --graph 的正确打开方式

前面提过--graph，这里展开说。最实用的组合是：

git log --oneline --graph --all --decorate

--decorate会在提交后面显示分支名和标签名，比如(HEAD -> main, origin/main, tag: v1.2.0)。这样你一眼就能看出当前 HEAD 在哪、哪些分支指向哪些提交。

输出大概长这样：

* a1b2c3d (HEAD -> main) fix: 修复精度问题 * 9f8e7d6 feat: 新增优惠券逻辑 |\ | * 5c4b3a2 (feature/coupon) feat: 优惠券叠加 |/ * 3a2b1c0 chore: 初始化

竖线表示分支，斜线表示分叉和合并。看多了之后，整个项目的分支演进一目了然。

6.2 简化历史与首次父提交

--first-parent是个很实用的选项。在合并提交处，它只跟随第一个父提交（通常是主分支那条线），忽略被合并进来的分支细节：

git log --oneline --first-parent main

这样看主分支历史会非常干净，每个合并提交就是一条记录，不会被 feature 分支内部的几十个提交淹没。做发布记录、写 changelog 时我基本都用这个。

--simplify-by-decoration则只显示被分支或标签指向的提交，适合快速看项目的里程碑节点。

6.3 查看合并提交的特殊处理

合并提交默认在git log里不显示 diff（因为 diff 相对两个父提交都有内容，展示起来复杂）。想看合并提交引入了什么，用-m或--cc：

git log -m -1 <merge-commit>

-m会把合并提交拆成对每个父提交的 diff 分别展示。--cc则只显示与所有父提交都不同的部分，也就是"冲突解决"的内容。实际排查合并引入的问题时，--cc更聚焦。

7. 时间与作者：那些容易搞混的细节

7.1 作者日期 vs 提交日期

前面提过，%ad是作者日期，%cd是提交日期。默认git log显示的是作者日期。这两个日期在以下场景会不同：

• rebase：作者日期保留原提交的时间，提交日期变成 rebase 执行的时间
• cherry-pick：同理
• amend：作者日期不变，提交日期更新

所以如果你用--since过滤，默认过滤的是提交日期，不是作者日期。想按作者日期过滤得加--author-date之类的选项（不同 Git 版本支持情况不同，较新版本有--since-as-filter等）。这个坑我在做发布记录时踩过：rebase 之后所有提交的提交日期都变成了同一天，按时间过滤就全乱了。

7.2 时区与相对时间

--date=relative显示"3 days ago"这种相对时间，适合快速判断新旧。--date=local转成本地时区，--date=iso用标准 ISO 格式。跨时区团队协作时，统一用--date=iso能避免很多沟通歧义。

7.3 按提交者过滤

--committer按提交者过滤，和--author对应。在 rebase 频繁的团队里，提交者往往是执行 rebase 的人，作者才是真正写代码的人。想查"谁把这个改动合进来的"用--committer，想查"谁写的"用--author。

8. 常见问题与排查技巧实录

8.1 常见问题速查表

8.2 几个我踩过的坑

第一个坑：--follow和路径过滤的顺序。--follow必须紧跟在--之前，且只能跟一个文件。写成git log --follow -- a.js b.js会报错。正确写法是git log --follow -- a.js。

第二个坑：--grep和-S可以组合。很多人不知道这两个过滤条件是"与"关系，可以一起用：

git log --grep="fix" -S"calculateDiscount" --oneline

这样能精准定位"提交信息里有 fix 且改动涉及 calculateDiscount"的提交，排查效率翻倍。

第三个坑：--all会包含远程分支和标签。有时候你只想看本地分支，结果--all把origin/xxx和一堆标签都带出来了。这时候用--branches只看本地分支，或者--remotes只看远程。

第四个坑：大仓库里git log -S很慢。因为它要遍历所有提交的 diff。在超大仓库里，先用--since缩小时间范围，或者用-- path缩小文件范围，能显著提速。

8.3 几个提升效率的别名

我习惯在~/.gitconfig里配几个别名：

[alias] lg = log --oneline --graph --all --decorate ll = log --pretty=format:"%h %ad %an %s" --date=short who = log --pretty=format:"%h %an %ad %s" --date=short --author find = log -S

这样git lg看全局拓扑，git ll看紧凑列表，git who 张三看某人提交，git find 函数名找引入点。每天能省下大量敲键盘的时间。

注意：别名里如果包含空格分隔的多个参数，Git 会正确解析。但如果参数里本身有空格（比如--author="Zhang San"），在别名里要小心引号嵌套，必要时用 shell 别名而不是 git 别名。

9. 把 git log 用成排查利器

git log的参数组合几乎是无穷的，但日常真正高频的就那么十来个。我的建议是先把--oneline、--graph、--all、-n、--author、--since、--grep、-S、-p、--stat这十个用熟，覆盖 90% 的场景。剩下的按需查文档。

真正让git log发挥价值的，不是记住所有参数，而是养成"遇到问题先查历史"的习惯。代码为什么变成这样、这个函数什么时候没的、这个 bug 是哪次提交引入的——这些问题git log基本都能回答。我现在的排查流程通常是：先git log --oneline -20看最近改动，锁定可疑范围后用git log -S"关键函数"找引入点，最后git show <commit>看具体 diff。三步下来，大部分"这代码怎么这样"的疑问都能解开。

最后分享一个我最近才用顺的技巧：git log --format="%H" -S"关键词" | tail -1能直接拿到某个字符串最早出现的那个提交哈希。配合git show就能看到它被引入时的完整上下文，追溯设计意图时特别好用。这个管道组合比翻文档找参数快多了。