GitLens不管理分支，仅可视化Git分支操作；切换/创建/删除分支可通过状态栏或资源管理器交互完成，底层调用git switch/checkout；Blame显示该行最后一次修改的提交而非当前分支修改；合并冲突前可用分支对比预判风险。
GitLens 本身不管理分支，它只是把 Git 的分支操作可视化、可交互化。真正管理分支的还是 git 命令和 VS Code 内置的源代码管理视图——GitLens 的价值在于帮你「看清谁在哪个分支改了什么」，而不是替代分支工作流。
怎么快速切换/创建/删除分支（不用敲命令）
GitLens 把分支操作集成到了资源管理器和状态栏里，比纯命令行更直观，但前提是理解它调用的是底层 git checkout 或 git switch：
- 点击 VS Code 左下角当前分支名（如
main），弹出分支列表 → 直接选目标分支即可切换；带「+」号的项支持新建（输入名后回车即执行git switch -c <name>） - 右键资源管理器中任意文件 → 「GitLens: Compare With Branch…」可对比当前分支与另一分支的差异，适合合并前验证
- 分支列表里右键某个远程分支（如
origin/feature/login）→ 「Create Local Branch From…」会自动 fetch 并创建跟踪分支，等价于git checkout --track origin/feature/login - 删除本地分支要右键分支名 → 「Delete Branch…」，注意它默认不强制（
-D），若提示“分支未合并”，得手动勾选「Force delete」
为什么「Current Line Blame」有时显示错分支的提交？
Blame 显示的是「该行最后一次被修改时所在的提交」，不是「当前分支上最近一次修改」。如果某行在 dev 分支改过，后来 dev 合并进 main，你在 main 上看这行 blame，仍会显示 dev 分支的提交记录——这是 Git 机制决定的，不是 GitLens bug。
- 开启「Blame Annotations」后，右键行号旁的作者信息 → 「Show Commit in Timeline」能跳转到对应提交，确认它是否属于预期分支
- 想只看当前分支的修改历史？用「GitLens: Open File Timeline」，它按时间倒序列出该文件在当前分支的所有提交，过滤掉 merge 进来的无关变更
- 如果 blame 显示「unknown author」或时间异常，大概率是该行来自 rebase 或 cherry-pick，原始 commit 元数据被重写，此时需结合「Compare With Previous Version」人工核对
如何用 GitLens 安全地处理 feature 分支合并冲突？
GitLens 不参与解决冲突，但它能让你在冲突发生前就预判风险点。关键在「Comparison」和「Commits」视图的组合使用：
- 切换到
main分支 → 打开「GitLens: Compare Branches」→ 选feature/login→ 查看「Changed Files」列表，重点关注那些在main上近期也被修改过的文件（比如多人同时改了package.json） - 点击某个高风险文件 → 右侧「File History」里展开最近 3 次提交，观察不同分支的修改是否集中在同一函数块，提前协调
- 合并后若出现冲突，GitLens 的「Code Lens」会在冲突标记（
<<<<<<）上方显示「Accept Current Change」/「Accept Incoming Change」快捷按钮，比手动编辑快，但别盲目点——先看左边「Changes」视图确认两边修改意图
GitLens 的分支相关功能越用越顺手的前提，是清楚它始终是 Git 的「放大镜」，不是「遥控器」。最易忽略的一点：它的所有分支操作都依赖本地仓库的最新状态，git fetch 没做全，右键「Create Local Branch From…」可能拉不到最新的远程分支，状态栏显示的分支列表也会滞后。
