先把一个很容易搞混的点说明白：GitLens 不是 VS Code 自带的 Git 模块。VS Code 本身已经内置 Source Control / Git 支持，直接调用电脑上安装的 Git；GitLens 则是 GitKraken 维护、需要另外安装的第三方扩展。它安装后会深度嵌入 VS Code 的编辑器、Source Control、侧边栏和各种 Git 视图，所以很容易让人误以为它就是“VS Code 内置 Git 的高级版”。
如果你长期用 VS Code、Cursor 这类编辑器写代码，GitLens 大概率并不陌生。它最早让很多人记住的功能，是在代码行尾直接告诉你“这一行是谁、什么时候、在哪个提交里改的”。但到了现在，它早已经不只是一个 Git Blame 增强插件。
官方入口可以这样区分：VS Code 自带 Git 看 VS Code Source Control 文档；GitLens 则是在 Visual Studio Marketplace 单独安装的扩展。
截至本文发布时，GitLens 官方 README 已经写到 5100 万+安装量，GitHub 仓库接近 1 万 Star、1800 Fork，最新稳定版为 v19.2.0。它现在真正想做的，是把 Git 历史、分支、Worktree、Pull Request、代码审核&查验，甚至正在工作的 Coding Agent，全都收进一个统一的开发工作台。
项目地址：GitHub - gitkraken/vscode-gitlens
官网：GitLens
GitLens 到底解决了什么问题？
Git 本身很强，但很多信息天然藏得比较深。平时想回答下面这些问题，往往要在编辑器、终端和 GitHub 网页之间来回切：
- 这段代码是谁改的？为什么改？
- 某个文件过去半年到底经历过什么？
- 当前分支比远端多了哪些提交？
- 几个 Worktree 里哪个还有未提交改动？
- 这个 PR 和哪些提交、Issue、分支有关？
- Claude Code、Codex 之类的 Agent 现在到底在改哪个 Worktree？
GitLens 的价值，就是把这些原本分散的信息变成“就在代码旁边、就在编辑器里、随时可以继续操作”的上下文。
最核心的变化：Commit Graph 已经像一个 Git 控制台
现在的 GitLens 最值得看的功能，我认为已经不是单纯的行内 Blame，而是 Commit Graph。
它把提交历史、分支、远端、Tag、Stash、Worktree、Pull Request、Working Changes 放在同一个图里，而且不只是“看”。你可以直接从图上完成：
- 切换分支、合并、Rebase、Cherry-pick、Revert；
- Push、Pull、Stash；
- 创建分支和 Worktree；
- 打开 Pull Request；
- 聚焦某个分支或 Worktree；
- 搜索作者、提交信息、文件和变更。
如果你维护的是一个分支很多、多人协作、又经常并行开发的项目，这种视图带来的价值会非常明显。它不是让 Git 变简单，而是让 Git 当前到底发生了什么变得更直观。
Visual History：终于不用靠脑子拼文件历史了
另一个非常实用的能力是可视化历史。传统 git log 能告诉你提交列表，但当你想知道“这个文件什么时候大改过”“最近是不是一直在高频修改”“主要是谁在维护”，纯文本历史并不直观。
GitLens 的 Visual History 会把变化时间、规模和作者关系做成图形化时间线。对于排查“某个问题从什么时候开始出现”、寻找最熟悉某个模块的人、分析代码频繁变动区域，这类信息比一串提交列表更容易理解。
Worktree + Coding Agent，可能才是现在最有意思的部分
过去 Worktree 更多是高级 Git 用户才经常使用的功能，但 AI 编程正在让它变得越来越重要。
原因很简单：当你自己在主任务上开发，同时让 Claude Code、Codex 或其他 Agent 并行处理另外几个 Issue 时，如果所有任务都挤在同一个工作区和分支里，很快就会乱。Worktree 天然适合把不同任务隔离到独立目录和分支中。
GitLens 现在已经开始把这件事产品化：
- 可以从分支、提交或 PR 快速创建 Worktree；
- 不同 Worktree 的未提交变化会直接显示在 Commit Graph；
- 可以在不同 Worktree 之间移动工作内容；
- Agent Session 可以直接出现在图里；
- 能看到 Agent 正在工作、空闲，还是正在等你确认；
- 可以从 Issue 直接创建分支/Worktree，再交给 Coding Agent；
- 还能通过 GitKraken MCP 给 Agent 提供结构化的 Git 历史、PR 和 Issue 上下文。
这也是我觉得 GitLens 最近最值得重新认识的一点：它正在从“辅助人理解 Git”，往“同时管理人和 AI Agent 产生的代码变化”演进。
AI 功能已经深入到 Commit、Review 和 Rebase
GitLens 现在的 AI 功能也不只是生成一句 Commit Message。官方已经加入了一整套围绕 Git 工作流的能力，包括：
- Explain Changes：解释某个提交、Stash、分支或当前工作区到底改了什么；
- Generate Commit Message：根据真实变更生成提交信息；
- Generate Pull Request：生成 PR 标题和描述；
- Generate Changelog：从分支、Tag 或选中的提交生成更新日志；
- Review Changes：在创建 PR 之前先让 AI 审核&查验整批变更；
- Compose Commits：把一大堆混在一起的修改拆成逻辑更清晰的多个提交；
- AI Resolve：辅助处理合并、Rebase 冲突。
对于经常让 Coding Agent 一次改很多文件的人来说，Compose Commits 特别有意思。AI Agent 很容易在一个任务里同时改代码、测试、配置、文档，最终变成一个很难审核&查验的大提交。GitLens 可以尝试把这些变化重新按逻辑拆分，让 Git 历史更像人认真整理过的结果。
v19.2.0 又进一步强化了 Worktree 和 Agent
目前最新稳定版是 2026 年 9 月发布的 v19.2.0。这一版有几项变化很能体现 GitLens 现在的方向：
- 开始加入实验性的简体中文、繁体中文和西班牙语本地化；
- Commit Graph 新增完整的 Worktree Scope，可以直接把整个图切换到另一个 Worktree 的视角；
- 可以保存 Commit Graph 布局作为以后工作区的默认布局；
- 支持恢复过去的 Codex、OpenCode、GitHub Copilot CLI Agent 会话；
- 可以对多选的 Commit 直接生成 AI Changelog；
- Worktree 里可以直接运行默认 Task；
- Agent、MCP、AI 模型状态在 Commit Graph 里变得更加清楚。
这已经明显不是传统“Git 辅助插件”的更新方向，而是在围绕现代并行开发和 AI Agent 工作流重新组织 Git 操作。
经典的 Blame、CodeLens 依然很好用
当然，GitLens 最经典的功能并没有消失，而且这些能力依然是免费版最值得安装的理由。
把光标放到某一行，GitLens 可以直接告诉你最近一次修改它的人、提交时间和 Commit 信息；Hover 后还能继续查看关联的 PR、Issue 和历史。文件顶部的 CodeLens 则能显示最近改动和作者信息。
当你接手一个陌生项目时，这些信息很有价值，因为代码本身只能告诉你“现在是什么样”，而 Git 历史往往能告诉你“为什么会变成这样”。
免费版和 Pro 要分清楚
GitLens 的仓库是公开的，但它并不是所有功能都采用同一种授权方式，这一点需要特别说明。
仓库中除 plus 目录以外的代码主要采用 MIT License；plus 目录里的 Pro 功能则使用单独的 GitLens Pro License，需要符合 GitKraken 的订阅许可。
GitLens Community 本身可以永久免费使用，包含 Blame、Hover、CodeLens、文件历史、Revision Navigation、侧边栏视图、Interactive Rebase Editor、Git Command Palette、集成能力以及 GitKraken MCP。
在公开仓库中，Commit Graph、Worktrees 和 Visual History 也可以免费使用；而私有仓库里的完整 Commit Graph、高级 PR 工作流、Agent Session、Launchpad 和多数 AI 功能则属于 Pro 范围。官方目前提供 14 天 Pro 试用，并注明无需信用卡。
它适合谁？
如果你只是偶尔提交几个个人项目，VS Code 自带的 Source Control 其实已经够用。但下面这些场景，GitLens 会明显更有价值：
- 经常接手陌生代码，需要快速理解“谁改过、为什么改”；
- 多人协作、分支和 PR 很多；
- 大量使用 Git Worktree 并行开发；
- 同时使用 Claude Code、Codex、Copilot CLI 等 Coding Agent；
- 希望减少编辑器、终端、GitHub 网页之间的反复切换；
- 希望 Git 历史更干净，Commit 和 PR 更容易审核&查验。
项目小档案
| 项目 | GitLens |
| 开发团队 | GitKraken |
| 类型 | VS Code Git 增强扩展 |
| 最新稳定版 | v19.2.0 |
| GitHub 热度 | 约 9936 Stars / 1801 Forks |
| 官方安装量 | 5100 万+ |
| 主要语言 | TypeScript |
| 授权 | 核心 MIT；Plus/Pro 部分使用 GitLens Pro License |
| GitHub | gitkraken/vscode-gitlens |
写在最后
GitLens 最有意思的地方，是它这些年并没有停在“给 VS Code 加个 Git Blame”上。
它正在把 Git 从一个需要不停查命令、切工具的底层系统，重新包装成一个可视化、可操作、能同时容纳 Worktree、PR 和 Coding Agent 的开发工作台。
尤其是在 AI 编程越来越普及以后，一个项目里同时存在多个分支、多个 Worktree、多个 Agent 会变得越来越常见。这个时候真正麻烦的已经不只是“AI 会不会写代码”，而是这些并行产生的工作到底发生在哪里、改了什么、怎么审核&查验、怎么整理成可以长期维护的 Git 历史。
从这个角度看，GitLens 现在的发展方向反而比过去更有价值。如果你已经在 VS Code / Cursor 里大量使用 Git 和 Coding Agent，我觉得它很值得重新装回来认真体验一次。
延伸阅读
如果你和我一样，是从“GitLens 不就是一个 Git 管理器吗？”这个疑问开始，可以继续看下面两篇：
- VS Code 内置 Git、GitHub Desktop、GitLens：关系梳理与能力对比：专门梳理 VS Code 内置 Git、GitHub Desktop 和 GitLens 三者的定位、能力差异与实际组合方式。
- GitLens Pro 14天试用指南：先学这6组功能：按 14 天试用期给一条具体体验路线，避免一打开几十个面板就不知道从哪开始。
评论