用Git的时候你有没有遇到过这种场景执行git commit之后终端里突然蹦出一个陌生界面光标闪来闪去按啥都没反应最后只能强行关掉窗口。如果你不是vim用户那一瞬间大概率是崩溃的。Git 在交互式场景下默认调用的是系统自带编辑器很多新手第一次提交就被卡在这一步然后就没有然后了。这篇文章就用最直白的方式把 Git 默认编辑器配置成 VS Code 或 Notepad 这件事讲透顺便把相关的命令行参数、配置文件、验证方法、常见坑位一次说完。看完之后你不仅能解决“提交时不知道怎么输入信息”的问题还能顺手把 Git 的全局配置理明白——以后不管是换电脑、换系统还是给不同仓库单独指定编辑器心里都有底。1. 为什么要设置Git默认编辑器先弄懂它到底卡在哪1.1 默认编辑器设置的背后原理很多人以为git commit -m 说明是唯一提交方式其实 Git 还有很多操作需要手动输入信息。当你执行git commit不带-m、执行git rebase -i、执行git merge遇到冲突需要写合并说明时Git 都会自动打开一个外部编辑器让你把内容写进去。这个“外部编辑器”在 Git 安装后有一个默认值。在 Linux 和 macOS 上通常默认是vi或vim在 Windows 上Git for Windows 默认可能是vim也可能是nano取决于你安装时选择的选项。问题在于新手根本不知道 vim 的操作方式怎么进入输入模式、怎么保存退出、怎么处理那些奇怪的花括号界面全是一头雾水。所以配置默认编辑器的核心目的只有一个让 Git 在需要你写内容时打开一个你真的会用、用着舒服的编辑器。VS Code 有图形界面、有中文输入法支持、有语法高亮Notepad 轻量、启动快、老机器也能跑。选哪个完全看个人习惯但配置方法都必须搞明白。1.2 Git配置的三个层级--global、--local、--system设置默认编辑器时你一定会反复看到--global这个关键词但它到底管多大范围很多人没细想。Git 的配置一共有三个层级优先级从高到低分别是层级配置命令配置文件位置生效范围仓库级git config --local可省略.git/config当前仓库全局级git config --global~/.gitconfig或C:\Users\你\.gitconfig当前用户的所有仓库系统级git config --systemGit 安装目录下的etc/gitconfig整台机器的所有用户如果你同时在多个层级配置了不同的编辑器Git 会优先采用仓库级的配置。比如你全局配置了 VS Code但某个仓库里希望用 Notepad就可以在那个仓库目录下单独执行一次配置覆盖全局设置。理解了这个层级关系后面操作就不会蒙圈。2. 动手前的准备检查Git和编辑器环境2.1 确认Git已安装并可正常使用配置看起来只是敲一条命令但如果 Git 本身没装好后面全是坑。我见过不少朋友在执行git config时提示找不到命令最后才发现 Git 根本没安装或者安装时没有把执行路径加到系统环境变量里。先打开终端Windows 上用 CMD 或者 PowerShell 都行推荐 PowerShell执行git --version如果正常返回类似git version 2.40.1.windows.1的输出说明 Git 已经可用。如果提示git 不是内部或外部命令那就得先安装 Git 或者重新配置 PATH 环境变量。Git 官方安装包在安装过程中有一个步骤叫 Adjusting your PATH environment务必选择中间那项 Git from the command line and also from 3rd-party software这样 Git 才能被各种终端正常识别。另外建议顺手查看一下 Git 版本。老版本对某些新特性支持不好虽然配置编辑器这种事情很老很基础但为了后续其他操作顺畅还是建议把 Git 升级到较新版本。2.2 VS Code的“战备”检查code 命令是否可用把 VS Code 配置成 Git 默认编辑器有两种常见的配置形式一种是配置为code --wait另一种是配置为 VS Code 的完整程序路径。无论用哪种都要先确认一个前提——VS Code 是否把命令行工具code安装到了系统 PATH 里。在 VS Code 中打开命令面板快捷键CtrlShiftP输入 Shell Command: Install code command in PATH执行之后 VS Code 会在你的系统路径里创建一个code软链接或入口。这样你在终端里输入code .就能直接用 VS Code 打开当前目录。验证方法很简单在终端执行code --version如果能输出版本号说明code命令已经可用。如果提示找不到命令那就先去 VS Code 里执行上面说的安装命令或者直接重启 VS Code 和终端。值得提醒的是在 Windows 上如果你是用安装包自动安装的 VS Code默认情况下code命令通常已经自动配置好了但用绿色版或者手动解压的朋友就需要手动补上这一步。2.3 Notepad的路径与安装形态确认Notepad 的配置核心在于路径。它没有类似 VS Code 的那种命令行快捷入口其实有notepad命令行但很多人没加到 PATH所以最稳妥的方法是把 Notepad 的可执行文件完整路径写到 Git 配置里。先确认 Notepad 安装在哪里。最常见的位置是C:\Program Files\Notepad\notepad.exe或者 32 位系统C:\Program Files (x86)\Notepad\notepad.exe如果你是从 Microsoft Store 安装的 Notepad那路径可能又不一样。建议先在文件管理器里找到notepad.exe把完整路径记下来再去做 Git 配置。这个细节看着不起眼但实际出错率非常高因为很多人把路径写错一个字母导致配置失效排查半天才发现。3. 把Git默认编辑器换成VS Code3.1 首选方法用git config命令一行搞定在终端里执行下面这条命令git config --global core.editor code --wait拆开解释一下。core.editor是 Git 配置项专门用来指定默认编辑器--global表示这是全局配置以后所有仓库都生效--wait是必须加的参数它告诉 VS CodeGit 启动编辑器后要等待编辑器窗口关闭再继续执行后续操作。如果不加--waitGit 执行到需要编辑器时它会启动 VS Code 但立即认为编辑已经完成于是直接读取一个还没写好的空文件继续执行。后果就是提交信息为空、rebase 流程错乱等诡异问题。所以--wait是这条配置的灵魂一定要带上。3.2 备用方法直接编辑.gitconfig文件除了敲命令还可以直接改配置文件。用任意编辑器打开用户主目录下的.gitconfig文件在文件里找到或添加下面这部分内容[core] editor code --wait保存后再执行git config --global --list看看输出中是否包含core.editorcode --wait。这种方式适合喜欢手动管理配置文件的人也适合在服务器等没有交互终端的环境下批量写入配置。3.3 为什么推荐“不等待”参数--wait的含义与作用很多教程只让你照抄命令不讲参数导致出问题后完全不知道怎么排查。--wait的本质是让code命令行工具进入“阻塞模式”。在正常情况下你在终端输入code它会启动编辑器后立刻返回终端可以继续执行下一条命令。但 Git 调用编辑器时不是这个逻辑它希望编辑器程序一直运行直到你关闭编辑器文件才继续读取文件内容。打个比方这就像你去银行柜台填单子你把填单这件事外包给别人如果不盯着他填完你拿到手的可能就是一张白纸。--wait就是那个“盯着”的动作确保 Git 拿到的文件是你真正编辑并保存过的。配置时如果遇到以下提示也不要慌warning: core.editor has multiple values这说明之前你在多个层级都配置过core.editor比如.gitconfig里写了一个系统级配置里又写了一个。Git 只会采用优先级最高的那个但你最好用git config --global --unset-all core.editor清理一下多余的配置项让配置环境保持干净。3.4 为VS Code配置时需要注意的细节VS Code 有多个版本稳定版Stable和 Insiders 版。如果你用的是 Insiders 版那么命令入口不叫code而叫code-insiders配置命令要改成git config --global core.editor code-insiders --wait很多用预览版的朋友在这上面栽过跟头一直用code --wait但编辑器没反应其实只是命令名不对。还有一点如果你希望 VS Code 在打开时自动聚焦到 Git 准备的临时文件上一般不需要额外配置。Git 传给编辑器的临时文件路径已经在命令行参数里了VS Code 会自然打开这个文件。如果你发现 VS Code 打开了但没显示 Git 的临时文件多半是用了错误的命令入口或者 VS Code 记住了一个固定的工作区把工作区关掉重试就行。4. 把Git默认编辑器换成Notepad4.1 一条命令配置Notepad相比 VS Code 的多版本差异Notepad 的配置思路更简单就是把可执行文件的完整路径告诉 Git。在终端执行git config --global core.editor C:/Program Files/Notepad/notepad.exe -multiInst -notabbar -nosession这里面有好几个细节需要注意。路径用单引号包了一层是为了防止路径中的空格把命令行参数拆散-multiInst表示每个 Git 操作都启动独立的 Notepad 实例避免和已经打开的窗口混在一起-notabbar是隐藏标签栏让 Git 创建的临时文件看起来更像一个单独的编辑窗口-nosession是不加载上次的会话记录防止 Notepad 启动时弹出一堆上次遗留的标签页。4.2 多实例场景Notepad的路径格式适配在 Windows 上配置路径时正斜杠和反斜杠都支持但建议用正斜杠。因为 Git 配置文件的解析器偶尔会吧反斜杠当成转义字符处理比如你写了git config --global core.editor C:\Program Files\Notepad\notepad.exe -multiInst在 Windows 路径下\P、\N这些组合可能被 Git 配置解析器误处理虽然很多情况下它也能正常工作但出了问题非常难排查。直接用正斜杠/就没这些麻烦。当然如果你是在编辑.gitconfig文件时手动写路径用正斜杠同样是最稳的选项。如果你没有把notepad.exe的完整路径记下来也可以在终端里用命令查找where notepad但要注意这个命令只有在 Notepad 安装目录被加进系统 PATH 时才有输出。大部分情况下Notepad 安装时不会自动加入 PATH所以最可靠的方法是手动到安装目录确认。4.3 Windows环境下反斜杠与引号到底该怎么写这是 Notepad 配置里争议最大、坑最多的地方。网上搜索能看到各种写法有人用双引号有人用单引号有人用cmd /c当开头。实际经验是最稳的写法就是单引号包裹路径参数跟在后面git config --global core.editor C:/Program Files/Notepad/notepad.exe -multiInst -notabbar -nosession在.gitconfig文件里对应的内容是这样的[core] editor C:/Program Files/Notepad/notepad.exe -multiInst -notabbar -nosession为什么不用双引号因为在部分 Windows Git for Windows 的组合下双引号会被 Git 配置解析器当作包含特殊字符的标记传递时反而会出问题。单引号在绝大多数情况下是安全的因为 Git 配置解析器会把它当作普通字符不会做特殊处理同时还能正确保留路径中的空格。注意如果你要编辑的.gitconfig文件本身是 UTF-8 编码的请务必用 UTF-8 without BOM 保存。带 BOM 的配置文件容易导致 Git 在读取时出现乱码或解析失败这个问题在 Windows 的记事本里尤其常见。5. 验证配置效果从提交信息到交互式命令5.1 用一个真实提交来测试编辑器是否生效配置完成后最重要的就是验证。打开任意一个 Git 仓库修改一个文件然后执行git add . git commit注意这里故意不带-m参数。如果配置正确Git 会启动你设置的编辑器并打开一个临时文件让你写提交信息。写完保存、关闭编辑器Git 会自动读取文件内容并完成提交。如果 Git 启动的还是 vim 或者其他编辑器说明配置没生效这时用下面命令查看当前值git config --global --get core.editor然后检查一下是不是仓库级配置覆盖了全局配置。在仓库目录下执行git config --local --get core.editor如果仓库级有值并且和全局的不一致那说明当前仓库用了单独的编辑器配置。这时要么删除仓库级配置要么把它也改成你想要的编辑器。5.2 其他会用到默认编辑器的Git操作默认编辑器不止在git commit时使用。以下操作都会触发编辑器配置不当时体验会很差git rebase -i 提交进入交互式变基界面需要编辑待变基的提交列表。git merge遇到冲突且没有提供-m参数时需要写合并记录。git commit不跟-m时最常用的场景。git tag -a添加带注释的标签时。git revert生成 revert 说明时。这些场景全部共用core.editor这个配置。所以配置好之后相当于一次解决所有需要交互式输入的 Git 操作收益非常大。5.3 查看当前配置的几种方式了解配置是否生效除了看行为还可以直接查配置值。常用命令# 查看全局的 core.editor git config --global --get core.editor # 查看当前仓库生效的 core.editor包括全局和仓库级的合并结果 git config --get core.editor # 列出所有相关配置项 git config --list | findstr editor最后一条是 Windows 用法会筛选出所有包含 editor 关键字的配置行。在 Linux/macOS 上用git config --list | grep editor效果一样。如果配置内容看起来没问题但行为不对还可以检查终端环境变量GIT_EDITOR。这个环境变量的优先级高于配置文件要是有系统管理员或某个工具帮你设置了这个环境变量它会覆盖你在.gitconfig里写的编辑器。这属于隐藏坑很多人不知道。6. 配置过程中常见的报错与排查思路6.1 编辑器没有启动命令直接卡住Windows 上执行git commit后终端卡住不动的场景非常常见。原因通常有两种一是编辑器程序确实启动了但窗口被隐藏到了后台或者启动失败但 Git 还在等待二是命令入口写错了Git 调用了一个不存在的命令然后一直挂在那边。第一种情况先看看任务栏里有没有 VS Code 或 Notepad 的图标。有的话说明编辑器启动了只是窗口焦点没到它上面切过去正常编辑保存就行。第二种情况的排查办法是手动在终端里执行配置的命令。比如你的配置是git config --global core.editor code --wait那就手动执行code --wait看终端是不是会卡住等待如果是说明命令本身没问题。如果提示找不到code那说明 PATH 还没配置好回第二章检查 VS Code 的命令行安装步骤。6.2 code 命令找不到code 不是内部或外部命令是个高频报错。在 Windows 上VS Code 安装时默认会设置 PATH但有两个例外一是你是通过便携版、绿色版使用 VS Code二是安装时取消了 添加到 PATH 那个勾选项它藏在 Install 页面的高级选项里。解决办法有很多种最简单的还是重新运行一次 VS Code 的安装程序把 Add to PATH 勾上。或者手动把 VS Code 的安装目录比如C:\Users\你的名字\AppData\Local\Programs\Microsoft VS Code\bin添加到系统的 PATH 环境变量里。添加完成后记得重开终端因为环境变量的更改不会立刻反映到已经打开的终端窗口。验证方式还是那句老话code --version。6.3 编辑器弹出但提交信息乱码有个现象是编辑器成功打开但里面乱码或者提交完成后 Git 历史里的中文信息显示的是一堆转义符。这个通常不是编辑器配置的问题而是 Git 对非 ASCII 字符的处理方式需要调整。在.gitconfig里加上这段[core] quotepath false加上之后Git 就不会把中文路径显示成\xxx的八进制转义形式了。另外在 Windows 上如果提交信息里中文乱码可以检查 Git for Windows 的安装选项里是否设置了正确的字符编码。一般设置为 UTF-8 就能解决绝大多数问题。编辑器本身的编码问题则不一样VS Code 默认使用 UTF-8Notepad 默认是 ANSI 编码如果你一直用 Notepad并且提交信息里经常出现中文乱码可以把 Notepad 的默认编码改成 UTF-8具体路径是“设置 → 首选项 → 新建”把默认编码改为 UTF-8 即可。6.4 编辑器配置报错速查表报错提示常见原因排查方向unable to start editor命令或路径写错手动执行配置的命令测试editor is not a valid program可执行文件路径不对用where或手动确认 exe 路径编辑器打开但 Git 立即完成缺少--wait参数补上--wait提交信息为空编辑后没有保存确认保存动作用git commit --amend补救提交历史中文显示成\xxx缺少quotepath false添加到[core]节这个表是我多次实战中整理出来的高频情况基本覆盖了 90% 的配置问题。遇到问题时先对号入座通常几分钟就能解决。7. Git配置的其他实用扩展让默认编辑器物尽其用7.1 全局配置中值得顺手设置的几个选项配置完编辑器之后其实可以再顺手把几个最常用的 Git 全局配置一起搞定省得以后反复折腾。git config --global user.name 你的名字 git config --global user.email 你的邮箱 git config --global init.defaultBranch main git config --global core.autocrlf input git config --global core.quotepath false git config --global color.ui auto这几个配置分别用来设置提交者姓名邮箱、把初始分支名设定为main而不是有争议的master、处理换行符转换、解决中文路径显示问题、启用终端颜色高亮。尤其是user.name和user.email不配置的话你根本没法正确提交因为 Git 会拦截并提示你需要先设置身份信息。7.2 为不同仓库指定不同编辑器全局配置适用于大多数情况但如果你有多个项目想用不同编辑器比如工作项目用 VS Code个人脚本项目用 Notepad那就在对应仓库目录下单独配置cd D:/work/my-project git config --local core.editor code --wait这样只影响这个仓库其他仓库仍然沿用全局配置。这种局部覆盖的能力来自 Git 配置的层级机制理解前面第 1.2 节的内容后这种操作就非常自然了。7.3 踩过的坑与个人体会配置 Git 默认编辑器这事看起来只是两行命令但我在实际使用中踩过的坑真不少这里分享几个值得记住的教训。第一个教训是在 Windows 上不要用系统自带的记事本notepad.exe作为 Git 默认编辑器。记事本无法正确处理 LF 换行符保存提交信息时会出现所有换行变成单一行的情况而且它不支持编码选择写入的文件可能带 BOM 头导致提交信息异常。这就是为什么大家普遍用 VS Code 或 Notepad 而不是记事本。第二个教训是编辑器路径里带有空格时一定要用单引号把整个路径包住。很多人都在这栽过跟头尤其是安装在C:\Program Files目录下的程序路径里有空格不包引号的话 Git 会把命令拆成两段直接报错。第三个教训是配置完成后一定要重启终端再测试。Git 在启动时会加载配置某些终端对配置文件的读取有时滞特别是 Windows 的 CMD 和 PowerShell 缓存比较明显。重启能让 Git 重新读取配置避免在旧环境里测试导致误判。7.4 日常使用中我建议的编辑器结合方式配置 VS Code 后我推荐一套组合用法平时提交信息简单的话继续用git commit -m xxx快速提交需要写详细说明时直接不跟-m让 VS Code 弹出写多行提交信息自动按规定格式排版。配置 Notepad 的话它的启动速度比 VS Code 快得多在低配电脑上体验更好。但它的编辑器体验稍微朴素一些没有拼写检查也没有 Markdown 预览。如果你经常需要写多行 Git 提交信息我个人还是偏向 VS Code它自带 Markdown 预览写完信息能直接看到渲染效果对养成交代清晰的提交习惯很有帮助。无论选哪个核心思路都一样把 Git 从“劝退工具”变成一个顺手顺心的工具。配置默认编辑器只是 Git 入门的一部分但把这一小步走稳后面学分支、学 rebase、学工作流都会舒服很多。最后分享一个小技巧当你配置完这些之后把.gitconfig文件备份一份放到云盘或者 GitHub 私有仓库里换电脑的时候直接下载覆盖再执行几个git config命令刷新下就全都回来了。第一次配置花了十分钟第二次只要一分钟这笔账怎么算都划算。