我后来才想起来一件很关键的事：GitLens 根本不是 VS Code 自带的 Git 模块，而是我以前另外安装、后来用久了给忘掉的第三方扩展。真正内置在 VS Code 里的，是 Source Control / Git 基础能力；GitLens 是 GitKraken 在这个编辑器里额外叠加的一整套高级 Git 工作流。
也正因为它嵌入得太深，我才一度把 Commit Graph、Blame、Worktree、Agent、Launchpad、AI Review 这些功能都下意识算成“VS Code 的 Git 管理器”。直到开了 14 天 Pro 试用认真研究，才发现问题变成了另一个：
不是功能不够，而是功能太多，多到不知道应该从哪里开始。
如果你也刚打开 GitLens Pro 就有这种感觉，这篇不打算把所有按钮再解释一遍，而是给一条更现实的学习路线：先掌握最值钱的 6 组能力，剩下的以后再说。
如果你还没搞清 VS Code 内置 Git、GitHub Desktop、GitLens 分别是什么，可以先看上一篇：《VS Code 内置 Git、GitHub Desktop、GitLens：关系梳理与能力对比》。
第 0 步：先确认你现在看到的是 VS Code 还是 GitLens
这个步骤其实比研究 Pro 功能更重要。你可以把它理解成两个叠在一起的层：
- VS Code 内置 Source Control / Git：不用安装 GitLens 也存在，负责 Changes、Stage、Commit、Branch、Push、Pull、基础历史和 Diff 等能力；它直接调用电脑上安装的 Git。
- GitLens：需要在 Extensions 中另外安装，由 GitKraken 维护；它增加 Inline Blame、File / Line History、Commit Graph、Visual History、Worktree 增强、PR、Agent、AI 等更深层能力。
最简单的验证方法就是：打开 VS Code 的 Extensions 搜索 GitLens。它可以被单独禁用或卸载；即使卸掉，VS Code 自带的 Source Control 依然能正常做基础 Git 操作。搞清这一点以后，后面判断“免费版够不够”“Pro 值不值得”才不会把 VS Code 本来就有的能力算到 GitLens 头上。
先回答最关键的问题：GitLens 是不是必须付费？
不是。GitLens Community 依然可以永久免费使用，而且很多最经典、最实用的能力都在免费版里。
按照 GitLens 当前官方说明，Community 免费版包括：
- Inline Blame、Hover、CodeLens；
- 文件和单行历史；
- Revision Navigation；
- 各种 Git 侧边栏视图；
- Interactive Rebase Editor；
- Git Command Palette；
- GitHub / GitLab 等集成；
- GitKraken MCP。
而且对公开仓库，Commit Graph、Worktrees、Visual History 也可以免费使用，Commit Graph 需要一个免费的 GitKraken 账号。
Pro 真正拉开差距的地方主要在：
- 私有仓库中的完整 Commit Graph / Worktree / Visual History；
- Agent Session 与 Agent Kanban；
- 更完整的 Pull Request 面板和 Launchpad；
- GitLens AI：Explain、Review、Compose Commits、Generate PR / Changelog、AI Resolve 等。
所以 14 天试用最应该测试的，不是“GitLens 能不能看 Git 历史”——免费版本来就能做很多；而是这些 Pro 能力对你的真实开发方式有没有形成不可替代的效率提升。
第 1 组：先把 Blame、File History 用熟，别一上来就折腾 Agent
GitLens 最经典的能力到今天仍然值得先学。
打开一个你自己维护过一段时间的项目，把光标放到代码行上，看 Inline Blame；再点开文件历史、单行历史、Commit Details。
你很快会发现，GitLens 真正方便的不是“告诉你谁改的”，而是把一条代码和它背后的 Commit、PR、Issue、作者、历史上下文串起来。
第一两天只用这些就够了。它们认知成本最低，而且马上能改善“我为什么当时这样写”的追溯体验。
第 2 组：把 Commit Graph 当成整个项目的地图
接下来再进入 Commit Graph，但先不要每个按钮都点。
先学会看五件事：
- 当前 HEAD 在哪里；
- 本地分支和远端分支是什么关系；
- 哪些提交还没 Push / Pull；
- 不同分支从哪里分叉、在哪里合并；
- Working Changes 和 Commit 历史怎么连在一起。
然后再学 Search、Compare、Focus / Scope。
到这一步，你就会开始理解 GitLens 和 GitHub Desktop 最大的差别：GitHub Desktop 更像一个非常好用的“当前仓库操作面板”，而 Commit Graph 更像是整个仓库的可交互地图。
第 3 组：如果你在做 AI 编程，Worktree 必须认真试一次
如果只是传统单人开发，Worktree 可能以前一直没有存在感。但有了 Codex、Claude Code、Copilot CLI 之后，它的重要性一下就上来了。
最典型的场景是：
- 主 Worktree：你自己继续做当前任务；
- Worktree A：交给 Codex 修 Issue A；
- Worktree B：让 Claude Code 重构一个模块；
- Worktree C：临时检查某个 PR。
每个任务有自己的目录、分支和 Working Tree，不需要不停 Stash 和切 Branch。
GitLens 现在可以直接从 Branch、Commit、PR 创建 Worktree，并在 Commit Graph 里看到每个 Worktree 是否 Dirty、当前分支、未提交变化。v19.2.0 还加入了完整的 Scope to Worktree，可以让整个 Commit Graph 临时切换到某个 Worktree 的视角。
如果你平时会并行跑多个 Coding Agent，我认为这一项很可能就是 Pro 试用里最应该认真测试的能力之一。
第 4 组：Agent Session——这才是 Pro 和普通 Git GUI 拉开差距的地方
GitLens 已经可以把部分 Coding Agent 会话映射进 Commit Graph。你能看到会话是正在工作、空闲，还是正在等你输入，并从对应 Worktree / Branch 继续恢复。
当前版本还在强化 Codex、OpenCode、GitHub Copilot CLI 等 Agent 会话恢复。
这类功能对只有一个 AI 对话的人可能没多大意义；但如果你已经开始同时让多个 Agent 做不同任务，它解决的是一个越来越现实的问题：
AI 会写代码以后，人接下来最缺的可能不是另一个 AI，而是一套“Agent 交通指挥系统”。
第 5 组：AI 功能别全试，先试 Explain、Compose、Review
GitLens Pro 的 AI 功能很多，但试用期我只建议优先看三个：
Explain Changes
选中一个 Commit、Branch、Stash 或 Working Changes，让 AI 直接解释“这批改动到底做了什么”。接手旧项目、检查 Agent 产出时特别实用。
Compose Commits
这是我觉得特别适合 AI 编程时代的一项能力。Agent 经常一次改十几个文件，把功能、测试、配置、文档混成一坨。Compose Commits 会尝试按逻辑重新拆成多个更容易审核&查验的 Commit。
Review Changes
在真正提交 PR 之前，对整个变化集做一次 Review，而不是你自己一份文件一份文件扫。然后还可以把问题继续交给 Agent 修。
至于 Generate Commit Message、Generate PR、Generate Changelog 这些当然也方便，但它们比较容易被其他 AI 工具替代。真正值得判断“要不要为 Pro 付钱”的，是 GitLens 能不能利用Git 上下文帮你完成其他 AI 不容易直接做好的工作。
第 6 组：最后再看 PR、Launchpad 和 Rebase
等前面几组熟悉以后，再去看 Pull Requests Panel、Launchpad、Interactive Rebase 和 AI Resolve。
这些功能很强，但如果一开始就从这里入手，很容易被几十个状态、按钮和操作劝退。
Launchpad 更适合 PR 很多、每天需要处理 Review 的人；Interactive Rebase / AI Resolve 则是在分支历史比较复杂时价值更大。
如果你的日常开发暂时还没遇到这些痛点，不需要为了“把试用功能全点一遍”强行学习。
14 天我建议这样安排
| 时间 | 重点 | 判断问题 |
|---|---|---|
| 第 1–2 天 | Blame、File History、Inspect | 理解旧代码有没有明显变快？ |
| 第 3–4 天 | Commit Graph、Search、Compare | 还会不会频繁切 GitHub Desktop / 终端查历史？ |
| 第 5–7 天 | Worktree | 并行任务是不是更清楚了？ |
| 第 8–9 天 | Agent Session / MCP | 多个 Agent 是否开始真正可管理？ |
| 第 10–11 天 | Explain / Compose / Review | AI 生成的变更是否更容易理解和整理？ |
| 第 12–13 天 | PR / Launchpad / Rebase | 团队协作和复杂 Git 操作有没有减少切换？ |
| 第 14 天 | 只复盘真实使用记录 | 过去一周有哪些功能你已经自然离不开？ |
哪些东西可以先完全无视？
第一次用 GitLens 最容易犯的错，就是觉得既然 Pro 试用只有 14 天，就必须每一个入口都研究明白。
其实完全没必要。刚开始这些东西都可以先放一边：
- 各种高级 Visualization / Treemap；
- Cloud Patches、Cloud Workspaces；
- 大量格式和 Annotation 自定义；
- 所有你当前项目根本用不到的 Hosting / Issue 集成；
- 为了体验而体验的 AI 功能。
GitLens 强的地方正是“可以很深”，但你不需要第一天就潜到底。
那 GitHub Desktop 是不是可以删了？
我现在反而不建议。
GitHub Desktop 依然有一个非常舒服的定位：独立、简单、可预期。
有时候我只是想：
- 快速确认改了哪些文件；
- 拆一下 Commit；
- Cherry-pick / Squash；
- Push / Pull；
- 在编辑器之外确认仓库状态。
这时候 GitHub Desktop 的低认知负担反而是优点。
完全可以形成这样一套分工：
| 工具 | 我建议的定位 |
|---|---|
| VS Code Source Control | 写代码时顺手 Stage、Diff、Commit |
| GitHub Desktop | 简单、独立的 Git GUI 和日常整理 |
| GitLens | 历史理解、Commit Graph、Worktree、PR、Agent 高级视角 |
| GitHub Copilot / Codex / Claude Code | 真正生成、理解和修改代码 |
| Git CLI | 精确、高级、自动化和兜底操作 |
它们不是五个互相争夺“唯一入口”的软件，而是五个层次不同的工具。
14 天后，什么情况下 Pro 值得继续？
我觉得可以用一个非常简单的标准判断。
如果你主要是：
- 个人小项目；
- 公开仓库；
- 很少同时维护多个分支 / Worktree；
- 不用多个 Coding Agent；
- PR 和 Review 也不复杂；
那么 GitLens Community 很可能已经足够强，没必要因为“Pro 功能很多”就付费。
但如果你正在进入这种工作方式：
- 大量私有仓库；
- 多个 Worktree 并行；
- Codex / Claude Code / Copilot 等 Agent 同时工作；
- 经常需要理解和整理 AI 生成的大批改动；
- PR、Review、Rebase 和 Commit 历史本身已经成为工作负担；
那 GitLens Pro 的价值就不再是“多几个按钮”，而是把一个越来越复杂的 Git + Agent 工作流收回到一个可观察、可整理的界面里。
写在最后
GitLens 最容易给人的第一印象是“太复杂了”。但换一个角度看，这种复杂其实来自它正在试图解决一个本来就越来越复杂的问题。
以前一个开发者往往只有：一个编辑器、一个 Working Tree、几个分支。
现在可能同时有：多个 Worktree、多个 PR、多个 Coding Agent、自动生成的 Commit、AI Review、Issue 和任务队列。
所以我现在不会急着问“GitLens 能不能替代 GitHub Desktop”，而会先问：
当开发开始从“我一个人在一个分支写代码”，变成“我在指挥多个并行任务和 Agent”以后，我是不是需要一个比普通 Git GUI 更高一层的视角？
如果答案是需要，那么 GitLens Pro 的 14 天试用就很值得认真用完。
延伸阅读：
VS Code 内置 Git、GitHub Desktop、GitLens：关系梳理与能力对比
GitLens：GitKraken 的 VS Code Git 与 AI Agent 工作台
评论