gitlens是唯一值得默认启用的git辅助插件，它叠加可交互元信息（如行级作者/时间/commit哈希），无需配置即可工作，但建议关闭冗余提示并根据性能调整hover/history设置。
VSCode 本身不依赖插件就能用 Git，所谓“版本控制辅助插件”解决的是原生功能覆盖不到的痛点：比如看不清谁改了哪行、查不到某次提交的上下文、搞不定合并冲突细节、或者想批量操作一堆文件。装错插件或配置不到位，反而会让 SCM 面板变卡、右键菜单消失、甚至干扰 git add 行为。
GitLens 是唯一值得默认启用的 Git 辅助插件
它不是替代原生 Git 功能，而是叠加一层可交互的元信息——比如在代码行左侧显示最近一次修改的作者、时间、提交哈希，点一下就能跳转到对应 commit；在文件比较视图里直接看到某段改动来自哪个分支合并；右键某行还能查“这段代码在历史上被修改过几次”。
- 安装后无需额外配置就能工作，但建议关掉
gitlens.advanced.codeLens.enabled（避免编辑器顶部堆满冗余提示） - 如果打开大仓库后明显卡顿，去设置里关掉
gitlens.hovers.enabled或调低gitlens.historyExplorer.enabled - 它会自动识别你当前项目用的是 Git，不会误激活在 SVN/TFS 项目里——这点比很多“全能型”插件靠谱
- 别和旧版 Git History 插件共存，两者都注册了
git.viewFileHistory命令，冲突时后者常静默失败
不要装“Git 插件合集”类扩展
像 Git Extension Pack、Git Pack 这类打包插件，本质是把十来个独立插件一键装齐，但其中多数已过时或与 VSCode 新版 API 不兼容。典型表现：右下角分支名突然不更新、git.statusBar.availability 设置失效、甚至导致 git.path 配置被覆盖。
- 真正有用的组件只有三个：
GitLens（可视化）、Git Graph（分支拓扑图）、Project Manager（多仓库快速切换）——其他如 “Git Blame” “Git History” 已被 GitLens 吸收 - 如果已装了合集包，先禁用它，再单独装 GitLens + Git Graph，重启 VSCode
- 某些合集包会悄悄改写
settings.json里的git.defaultBranchName，导致git init默认创建main而非master，和团队规范不一致
SVN/TFS 用户必须手动指定可执行文件路径
VSCode 对非 Git 版本控制系统完全不内置支持，所有操作都靠调用外部命令。插件只是 UI 层，底层全靠 svn 或 tf 可执行文件。装完插件却看不到状态栏图标？90% 是路径没配对。
- SVN：确认终端能跑
svn --version，然后在 settings.json 加"svn.path": "/usr/local/bin/svn"（macOS）或"svn.path": "C:\Program Files\TortoiseSVN\bin\svn.exe"（Windows） - TFS/TFVC：必须用
tf.exe，不是tf.cmd；路径要精确到 .exe，且需 Visual Studio 的 Team Explorer 组件支持；填"tfvc.location": "C:\Program Files (x86)\Microsoft Visual Studio\2022\Community\TeamTools\TF.exe" - 路径含空格或中文时，VSCode 某些版本会静默忽略配置——换到纯英文路径最稳
- 插件启用后，状态栏出现 SVN 图标才代表连通成功；否则 Ctrl+Shift+P 输入
SVN: Update报错，说明根本没调起 svn 进程
插件不是越多越好，关键看它是否补足了你每天真实卡住的环节：是想快速定位某行代码的来龙去脉，还是需要看清分支合并线？前者 GitLens 足够，后者 Git Graph 更直观。盲目堆插件，反而会让 git add 变慢、SCM 刷新延迟、甚至让 git.path 配置失效——这些都不是玄学，是插件间命令注册冲突或资源争抢的直接结果。
