gitLens 是 vs code 的 Git 增强插件，核心价值在于精准追溯代码变更（谁、何时、为何修改），需手动启用行内 blame；支持 Show history 查看某行演进脉络，但受 git blame -L 限制；合并冲突时慎用 Compare With Previous Revision，推荐 Open Changes With Working Tree/HEAD；Search Commits 可辅助定位问题提交。
GitLens 不是 Git 的替代品，而是让 VS Code 里的 Git 操作更“可读、可溯、可比”。它真正有用的地方，不是看提交记录，而是快速定位某行代码是谁、什么时候、为什么改的——尤其在接手老项目或排查线上问题时。
安装后必须启用 GitLens 的行内 blame 提示
装完 GitLens 默认不会在编辑器右侧显示 blame 信息，得手动打开。否则你点右键也看不到 GitLens: Toggle Blame Annotations。
- 按
Ctrl+Shift+P（windows/linux）或Cmd+Shift+P（macOS），输入GitLens: Toggle Blame Annotations并执行 - 或者点击右下角状态栏的
Blame按钮（默认显示为作者名 + 提交简写，如@alice a1b2c3d） - 若状态栏没出现
Blame，检查是否已打开一个受 Git 管理的文件，且该文件有提交历史
用 GitLens: Show History 查看某行/某函数的变更脉络
光看 blame 行注释不够——它只告诉你“最后谁改的”，但你想知道“这段逻辑是怎么一步步变成现在这样的”，就得用历史视图。
- 把光标放在任意一行，右键 →
GitLens: Show History，会弹出侧边栏列出所有修改过这行的提交 - 点击某次提交，右侧会高亮显示本次提交中该文件的 diff；再点左侧文件名，可跳转到该次提交的完整快照
- 注意：如果某行被多次移动（比如函数重命名、文件拆分），
Show History可能断链；此时换用GitLens: Show File History更稳妥
别忽略 git blame -L 底层行为带来的限制
GitLens 的 blame 功能本质调用的是 git blame -L，所以它继承了 Git blame 的所有边界条件：
- 对空行、纯注释行、刚新增未提交的行，blame 无结果（状态栏不显示，右键菜单也不出现相关项）
- 如果某次提交中该行被删除又重建（例如整块重写），blame 会“断档”，显示为最近一次插入它的提交，而非原始作者
- 大文件（>1MB）或超长历史（>1000 次提交）下，首次加载 blame 可能卡顿数秒；可临时禁用
"gitlens.advanced.blame.ignoreWhitespace": true加速
合并冲突时慎用 GitLens: Compare With Previous Revision
这个功能看着方便，但在 merge conflict 状态下容易误判。VS Code 此时打开的是 index 中的暂存版本，而 GitLens 默认比较的是工作区 vs HEAD，两者语义不同。
- 冲突中右键选
Compare With Previous Revision，实际比的是“当前冲突态” vs “HEAD”，不是你想要的“本地修改 vs 远程修改” - 真要对比双方变更，请先用 VS Code 内置的
Accept Current Change / Accept Incoming Change进入单边编辑态，再调用 GitLens 比较 - 更稳的做法：用
GitLens: Open Changes With Working Tree（对比工作区）或Open Changes With HEAD（对比最新提交）
GitLens 最容易被低估的其实是它的搜索能力——比如用 GitLens: Search Commits 输入函数名或错误码，常能直接定位到引入 bug 的那次提交。但这依赖提交信息写得清楚，不是所有团队都做到这点。