git面板“+”按钮仅强制添加未跟踪文件，非git add -a；暂存修改需右键“stage changes”或命令面板执行git: stage all。
Git 面板里点“+”不等于 git add，它只加未跟踪文件
VS Code 的源代码管理面板顶部“+”按钮，默认行为是 git add -A 吗？不是。它实际执行的是 git add -f（强制添加）但仅限于当前工作区里「从未被 Git 跟踪过」的文件——已忽略、已删除、已修改但未暂存的文件，它一概不管。
容易踩的坑：
你改了 package.json，又新建了 utils/helper.js，点“+”后发现只有 helper.js 进了暂存区，package.json 仍灰着——这不是 bug，是设计如此。
- 真正想暂存所有修改，右键文件 → “Stage Changes”，或用命令面板运行
Git: Stage All - 如果想让“+”也包含修改文件，需手动改设置：
git.ignoredRepositories不影响这个行为，但可以启用git.autofetch配合手动 stage 更稳 - 批量 stage 多个修改文件时，别依赖“全选 + 右键”，VS Code 会按字母序排序，而 Git 暂存顺序无关紧要；但如果你在写 commit message 时想按逻辑分组，建议先 stage 再写，别倒过来
解决冲突时，“Accept Current Change”和“Accept Incoming Change”反直觉
左侧是“Current Change”（你本地的），右侧是“Incoming Change”（远端的）——这没错。但 VS Code 默认把当前分支显示在右边，远端分支（比如 origin/main）显示在左边，视觉上就和文字标签对不上。
常见错误现象：你刚 git pull 报冲突，打开文件看到左边有绿色块写着“Accept Incoming Change”，下意识点了，结果把远端改的给“接受”进自己分支——可你其实是想保留自己的修改。
- 先看顶部状态栏：它会明确标出
HEAD在哪（比如main），那个分支的内容就对应“Current” - 点“Accept Current Change”= 丢弃远端改动，只留你本地的；点“Accept Incoming Change”= 丢弃你本地的，全用远端的
- 更安全的做法：点“Accept Both Changes”，再手动删掉不需要的那部分，尤其涉及 JSON 或配置项增删时
git blame 插件没装也能看谁改的，但得用命令面板触发
VS Code 内置支持 git blame，但不像 IDE 那样鼠标悬停就弹出作者信息——它需要主动调用。很多人以为没装插件就看不到，其实只是入口藏得深。
使用场景：线上 bug 定位到某行，你想立刻知道是谁、什么时候、为什么改的这行，而不是切终端敲命令。
- 光标放在任意行，按
Ctrl+Shift+P（macOS 是Cmd+Shift+P），输入Git: Blame并回车 - 行首会立刻出现浅灰小字，格式是
author@hash date，比如alice@abc123 2024-03-15 - 注意：如果该行最近被 rebase 过，blame 显示的是最终提交者，不是原始作者；想追原始提交，得用
git blame -S <original-commit></original-commit>，VS Code 不支持这个参数
撤销 git commit 但保留修改，用“Undo Last Commit”最稳
误提交了敏感信息（比如密钥、本地路径）或忘了 git add 某个关键文件，想撤回 commit 但不让工作区变干净——这时候别手抖去 git reset --hard HEAD~1，VS Code 提供了更可控的路径。
性能影响：它本质是 git reset --mixed HEAD~1，不会重写历史，也不影响其他协作者，适合单人修复。
- 打开源代码管理面板，点击右上角 “⋯” → “Undo Last Commit”
- 它会把 commit 撤销，同时把所有变更文件重新放回“Changes”区域（即未暂存状态），你可以补加、改 message、再 commit
- 如果已经
git push过，这个操作就无效了——VS Code 会禁用该菜单项，并提示 “Cannot undo pushed commits” - 想连暂存区也一起还原（即回到“未暂存”+“未修改”状态），得用
git reset --soft HEAD~1，但 VS Code 没提供这个快捷入口
切换分支卡住不动？检查 .git/index.lock 是否残留
VS Code 切分支时转圈、无响应、甚至整个 Git 面板灰掉——大概率不是网络或权限问题，而是 .git/index.lock 文件没被正常释放。常见于异常退出、杀进程、或另一工具（如 Sourcetree）同时操作同一仓库。
路径就是项目根目录下的 .git/index.lock，它是个空文件，Git 正在写索引时创建，完成后自动删掉。
- 先关掉所有可能访问该仓库的程序（包括终端里的
git status进程） - 手动删掉
.git/index.lock（Windows 下可能需要管理员权限） - 不要用 VS Code 自带的“Refresh”按钮清缓存，它不处理 lock 文件；重启 VS Code 也无效，lock 文件还在就还会卡
- 删完后，在 VS Code 里随便点一下 Git 面板，通常立刻恢复响应
查看某次 commit 的具体变更，别只点“Commits”列表
在“Commits”面板里点一个提交，只显示 message 和 author，看不到 diff——这不是功能缺失，是 VS Code 把 diff 放到了另一个视图里。
为什么这样做：避免每次点 commit 都加载大量文件变更，影响响应速度；尤其大仓库里，一次 commit 改上百个文件，全展开会卡顿。
- 右键目标 commit → “Show Commit Details”（不是“Open File”）
- 新标签页打开后，左侧是文件列表，右侧是逐个文件的 diff，支持语法高亮和行内编辑
- 如果 commit 包含二进制文件（如图片、压缩包），diff 区域会显示 “Binary files differ”，无法预览内容——这是 Git 本身限制，VS Code 无法绕过
git stash，面板里 stash 列表不会自动更新。这类不同步不是 bug，是 VS Code 主动做了防抖——它每 5 秒轮询一次 git status，中间的间隙就得靠你手动点“Refresh”或开“Auto Refresh”设置。
