ctrl+alt+h没反应是因为blame未就绪：文件需已git add或提交、工作区须识别为git仓库（状态栏显示分支名）、且gitlens.blame.lineenabled必须为true。
Ctrl+Alt+H 为什么没反应？先确认 blame 是否已就绪
快捷键 Ctrl+Alt+H（Windows/Linux）或 Cmd+Option+H（macOS）是 GitLens 最常用的手动开关行内 blame 的方式，但它不会无条件生效。它只在满足三个硬性条件时才起作用：当前文件必须已提交或至少 git add 过；VS Code 工作区根目录下存在有效的 .git 目录且状态栏显示分支名（如 main）；设置项 gitlens.blame.lineEnabled 必须为 true。常见误判是看到插件已启用就以为万事大吉——其实只要文件还在 Untracked 状态，Ctrl+Alt+H 就只会静默失败。
右键菜单不出现 “Show Line History”？别等它自动弹出来
这个菜单项默认不注入上下文，不是 bug，是设计如此。团队协作中常有人反复右键却找不到入口，白白浪费时间。正确做法是直接调用命令面板：Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入并执行 GitLens: Show Line History。结果为空？说明该行从未被单独修改过——可能是整块粘贴、函数重写，或从其他文件复制而来，Git 无法建立行级连续性。只返回 1 条记录？大概率是这行自首次提交后就没变过，或者后续全是空格/换行改动（被 gitlens.history.excludeTrivialCommits 折叠了）。
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
对比两个 commit 时 diff 为空？问题出在路径与版本连续性上
GitLens: Compare with Previous Revision 表面方便，实则限制极多。它只对比当前工作区与 HEAD~1，要求文件至少有两次提交；若当前文件有未暂存修改（git status 显示 modified），会直接报 no previous revision；选中几行再调用，它只 diff 这几行——但前提是这些行在 HEAD~1 中真实存在。若上一版删了又重建，diff 就为空白。真要对比任意两个 commit（比如 abc123 和 def456），必须先打开 GitLens: Open File Timeline，手动选择目标版本，再点击 Compare with Revision。
多人协作审查时，怎么避免“谁改的”变成“谁背锅”？
GitLens 显示的作者信息只是 Git 提交元数据，不等于逻辑责任人。比如某次 rebase 后，原始 commit hash 失效，GitLens: Show Line History 可能仍显示旧作者，但实际代码已由他人重构；又比如 merge 提交中引入的变更，若未启用 gitlens.advanced.git.enableMergeCommits，就会跳过合并点，导致溯源断层。审查时务必结合 GitLens: Open File Timeline 查看完整演进路径，并留意 commit message 是否含 Co-authored-by 或关联 issue 编号——这些才是责任归属的关键线索。
