github copilot 需在支持编辑器中打开 git 仓库根目录并启用 scm 支持，输入 feat:、fix: 等前缀后触发补全，依赖当前文件内容而非提交历史，不工作于 vim 默认模式、blame 视图或终端 log 输出。
GitHub Copilot 在 Git 提交信息里怎么用才不翻车
它不会自动写 git commit -m 的内容，但能帮你补全、润色、甚至生成符合 Conventional Commits 规范的提交说明——前提是你要先打下开头几个字，比如 feat: 或 fix:，再按 Tab 或 Enter 触发建议。
常见错误现象：git commit 后弹出编辑器，你空着标题直接保存，结果 Copilot 一动不动；或者你写了个模糊描述如“改了点东西”，它根本没法推断上下文。
- 必须在支持 Copilot 的编辑器（VS Code / JetBrains IDE）中打开 Git 仓库根目录，且已启用
git.editor配置为该编辑器 - 提交前先在编辑器中打开一个暂存文件，让 Copilot 感知变更内容；否则它只看空编辑框，补全质量极差
- 推荐在
.gitmessage模板里预设结构，比如第一行留空、第二行起写 body，Copilot 对这种格式响应更稳 - 别依赖它生成敏感信息：比如把
API_KEY=xxx误提交后，Copilot 可能顺着上下文补出类似密钥格式的字符串
VS Code 中 git add 后 Copilot 不提示变更摘要？检查这三处
Copilot 不监听 git add 命令本身，它只读取当前编辑器打开的文件内容 + git index 差异。如果没提示，大概率是它“看不见”你刚 git add 的文件。
- 确保文件已在 VS Code 编辑器标签页中打开（哪怕只是只读状态），Copilot 才会结合 staging 状态生成描述
- 检查设置：
"github.copilot.enable": { "scm": true }必须为true，默认可能关闭 - Windows 上若用 WSL2，VS Code 必须以 WSL 远程模式打开项目，否则 Copilot 看不到
git status输出，无法判断 staged/unstaged
git rebase -i 时 Copilot 能不能帮写 squash 提交信息
能，但只在你手动编辑 pick 行并改成 s 或 f 后，光标移到新合并的提交标题行开头时触发。它不会主动弹窗，也不会覆盖原有标题。
容易踩的坑：rebase 编辑器默认是 vim，Copilot 在 vim 普通模式下完全不工作；必须先进入插入模式（按 i），再输入开头字符（如 refactor:）才能唤出建议。
- 临时切编辑器：运行
git config --global core.editor "code --wait"，避免 vim 陷阱 - 多个
squash合并时，Copilot 建议基于第一个pick行的原始信息，不是所有被 squash 文件的 diff 总和 - 如果原始提交信息含 emoji（如 ?），Copilot 可能忽略它们，生成纯文本版本——别指望它保留风格
为什么 git blame 页面里 Copilot 不给注释建议
因为 Copilot 默认不激活在只读、无语法高亮的 blame 视图中。这不是 bug，是设计限制：它需要可编辑上下文 + 语言服务支持，而 git blame 输出是纯文本流，没有 AST。
- 变通做法：右键某行 →
Go to Definition或Open File at Line，跳转到源码真实位置，那里 Copilot 正常工作 - 不要在
git log -p终端输出里期待 Copilot —— 它压根不注入终端进程 - 某些插件（如 GitLens）扩展了 blame 视图，但 Copilot 仍不会自动接入，得靠插件自身集成（目前 GitLens 未开放此 API）
最常被忽略的一点：Copilot 的建议质量严重依赖你当前文件的命名、已有注释、函数签名，而不是 git 提交历史本身。它不“读” .git/ 目录，只“看”编辑器里开着什么、写了什么。想让它准，先让自己写的代码有迹可循。
