Windows下Git Bash终端高效配置全指南

1. 为什么一个终端配置值得花两小时认真对待？

Git Bash 在 Windows 上不是“能用就行”的玩具，它是你每天和代码、脚本、远程协作打交道的主战场。我见过太多人卡在几个看似微小却反复消耗时间的环节里：中文乱码像乱码电报一样跳出来、Ctrl+V 粘贴直接崩掉、路径复制粘贴后多出一串反斜杠、alias 写了十次都生效不了、ssh-agent 每次重启都要手动启动……这些不是“小问题”，是每天叠加 3 分钟、一个月就浪费 15 小时的隐形效率黑洞。

核心关键词——Windows、Git Bash、终端、配置——背后真正要解决的，是让这个轻量级 POSIX 兼容层，在 Windows 生态里真正“活”起来：它得像 Linux 终端一样直觉，又得无缝兼容 Windows 文件系统、剪贴板、网络环境和常用工具链。这不是改几行配置的事，而是一整套工作流的底层基建。适合谁？所有用 Windows 做开发、运维、数据处理、甚至只是写点 Python 脚本的人。哪怕你只用 VS Code 内置终端，它的底层很可能就是 Git Bash；哪怕你装了 WSL2，Git Bash 仍是快速执行 git、curl、sed、awk 的零依赖首选。它不替代 WSL，但补足 WSL 不擅长的轻量交互场景——比如快速拉个仓库、批量重命名文件、调试 shell 脚本、或者给同事发一段可直接复制粘贴的命令。

我从 2014 年开始在 Windows 上用 Git Bash，经历过从 1.9 到 2.43 的全部大版本迭代，亲手踩过所有常见坑：早期 mintty 渲染器对 Unicode 支持差导致 emoji 显示为方块；Git for Windows 自带的 OpenSSH 和系统 OpenSSH 冲突导致 ssh-add 失效；PATH 中混入 Cygwin 路径引发命令优先级错乱；甚至因为 .bashrc 加载顺序不对，导致 oh-my-bash 主题加载失败后整个 shell 启动卡死。这些都不是文档里写的“按步骤操作即可”，而是真实世界里需要你理解底层机制才能绕开的暗礁。这篇指南，就是把这十年间沉淀下来的判断逻辑、验证过的参数组合、以及那些“试了三次才敢写进配置”的实操细节，一次性摊开给你看。

2. 整体设计思路：三层架构，稳准狠

Git Bash 的配置不是堆砌功能，而是构建一个稳定、精准、可复用的终端环境。我把它拆成三个逻辑层，每一层解决一类根本性问题，层层递进，互不干扰：

2.1 底层：mintty 渲染器与输入输出管道（决定“能不能用”）

Git Bash 的 GUI 界面由 mintty 驱动，它不是简单的字符显示器，而是一个独立的终端仿真器。很多人以为改.bashrc就完事，其实第一步就错了——如果 mintty 本身不支持 UTF-8 或者键盘映射混乱，后面所有 shell 配置都是空中楼阁。关键点有三个：

• 编码必须锁定为 UTF-8：Windows 默认是 GBK，而现代开发（尤其是前端、Python、Go）默认用 UTF-8。mintty 的Locale和Charset必须显式设为en_US.UTF-8和UTF-8，否则中文文件名显示为???.txt，ls结果全是问号。
• 键盘映射必须关闭 Windows 原生快捷键劫持：默认情况下，Ctrl+C/V 是 Windows 剪贴板行为，但在终端里它们应该是信号发送和粘贴。mintty 的Copy and paste设置里，“Use Ctrl+Shift+C/V as copy/paste” 必须勾选，同时取消 “Use Ctrl+Insert/Shift+Insert” 这类冗余绑定，避免快捷键冲突。
• 字体渲染必须启用 ClearType + 等宽字体：Windows 的字体渲染默认为“标准”，在终端里文字边缘发虚。mintty 的Text appearance里，“Enable ClearType” 打开，“Font smoothing” 设为 “Standard”，字体选Consolas或JetBrains Mono（后者免费且专为编程优化），字号 10–12px 最佳。实测下来，Consolas在高 DPI 屏幕上偶尔有轻微模糊，JetBrains Mono则全程锐利，且对0OIl1这类易混淆字符做了明确区分。

提示：mintty 配置文件是~/.minttyrc，不是注册表也不是 Git Bash 安装目录下的某个 conf。它只影响当前用户的 Git Bash 窗口，修改后无需重启，关闭再打开新窗口即生效。这是最安全的起点——改错了最多窗口显示异常，不会破坏 shell 功能。

2.2 中层：Bash 运行时环境（决定“好不好用”）

这一层是.bashrc和.bash_profile的主战场，但绝大多数人栽在“不知道该写在哪”和“不知道加载顺序”。Git Bash 启动时，会按固定顺序读取配置文件：

1. /etc/profile（系统级，不建议改）
2. ~/.bash_profile（用户级，仅登录 shell 加载一次）
3. ~/.bashrc（用户级，每个新终端窗口都加载）
4. /etc/bash.bashrc（系统级，不建议改）

关键结论：所有日常终端配置，一律写进~/.bashrc。.bash_profile只放极少数需要登录时一次性执行的命令，比如启动 ssh-agent（见后文）。.bashrc里要做的三件事：

• PATH 重构：Windows 的 PATH 常含C:\Windows\System32、C:\Program Files\Git\cmd等路径，但 Git Bash 的/usr/bin优先级更高。必须确保/usr/bin和/bin在 PATH 最前面，否则ls可能调用到 Windows 自带的ls.exe（不存在），报错command not found。正确写法：

  export PATH="/usr/bin:/bin:/usr/local/bin:$PATH"

• Shell 选项精细化控制：shopt命令能开启 Bash 的隐藏能力。必开三项：
  • globstar：支持**递归匹配，cp -r dir/**/* ./backup/直接复制所有子目录文件；
  • autocd：输入目录名直接进入，不用打cd；
  • direxpand：Tab 补全时自动展开路径，cd /u<Tab>直接变成cd /usr/。
• 历史记录持久化与智能搜索：默认历史只存 500 条且不跨会话。加两行：

  export HISTSIZE=10000 export HISTFILESIZE=20000 export HISTCONTROL="ignoredups:ignorespace" # 忽略重复命令和以空格开头的命令 # 按上下箭头搜索历史（非默认，需绑定） bind '"\C-p": history-search-backward' bind '"\C-n": history-search-forward'

  这样输入git后按 Ctrl+P，就能逐条翻出所有git开头的命令，比默认的history | grep git快十倍。

2.3 上层：用户级功能增强（决定“爽不爽用”）

这是个性化部分，但必须建立在前两层稳固的基础上。我推荐四个模块，全部经过生产环境验证：

• 别名（alias）精简集：不堆砌，只放高频、防错、提效的。例如：

  alias ll='ls -alF --color=auto' # 颜色+详细+文件类型标识 alias gs='git status -s' # 状态缩写，一眼看清变更 alias ga='git add' # 防止手滑输成 git a alias gco='git checkout' # checkout 太长，易输错 alias ...='cd ../..' # 快速向上两级

  注意：alias不能替代函数。比如git log常用图形化视图，用函数更灵活：

  gitlg() { git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative }

• 自动补全增强：Git Bash 自带git-completion.bash，但默认没启用。下载最新版（ https://github.com/git/git/blob/master/contrib/completion/git-completion.bash ），存为~/.git-completion.bash，然后在.bashrc末尾加：

  if [ -f ~/.git-completion.bash ]; then source ~/.git-completion.bash fi

  效果：git co<Tab>自动补全为git checkout，git checkout ma<Tab>补全为git checkout main，git push ori<Tab>补全为git push origin。
• SSH 密钥自动管理：每次新开终端都要eval $(ssh-agent -s)+ssh-add ~/.ssh/id_rsa太麻烦。.bash_profile里加：

  # 启动 ssh-agent 并加载密钥（仅登录 shell 执行一次） if [ -z "$SSH_AUTH_SOCK" ]; then eval $(ssh-agent -s) ssh-add ~/.ssh/id_rsa 2>/dev/null fi

  这样只要开机后第一次打开 Git Bash，后续所有窗口共享同一个 agent，git push再也不用输密码。
• 提示符（PS1）实用主义改造：默认user@PC MINGW64:/path $太长。我用精简版：

  PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\] \[\033[01;33m\]\$(__git_ps1 "(%s)")\[\033[00m\]\$ '

  效果：user@PC:/c/Users/name (main)$—— 用户名+主机名（绿色）、当前路径（蓝色）、当前 Git 分支（黄色括号包裹）、最后是$。分支名实时显示，切分支立刻更新，比任何外部插件都准。

3. 核心实操：从零开始的完整配置流程

下面是一份可直接复制粘贴、逐行执行的配置清单。我按真实操作顺序组织，每一步都说明“为什么这么做”和“不做会怎样”。

3.1 初始化：创建干净的用户配置目录

Git Bash 安装后，~（即C:\Users\YourName）下默认没有.bashrc或.minttyrc。不要手动新建空文件——Git Bash 会用默认模板覆盖。正确做法是先生成一份基础配置：

# 打开 Git Bash，执行以下命令（一行一个） cp /etc/skel/.bashrc ~/ cp /etc/skel/.bash_profile ~/ touch ~/.minttyrc

解释：/etc/skel/是系统模板目录，.bashrc和.bash_profile里已包含基础 PATH 和函数定义。直接复制，比从零写更可靠。touch ~/.minttyrc创建空文件，为后续编辑做准备。此时打开新终端，已是标准 Git Bash 行为，无任何异常。

3.2 配置 mintty：解决显示与输入的根本问题

用 Notepad++ 或 VS Code 打开C:\Users\YourName\.minttyrc（注意是隐藏文件，需在资源管理器设置显示隐藏文件），粘贴以下内容：

# 字体与渲染 Font=JetBrains Mono FontHeight=11 Antialias=Yes ClearType=Yes # 编码 Locale=en_US.UTF-8 Charset=UTF-8 # 键盘与剪贴板 CtrlClick=none CtrlShiftClick=none CtrlShiftC=copy CtrlShiftV=paste CtrlInsert=none ShiftInsert=paste # 窗口与外观 Transparency=0 OpaqueWhenFocused=Yes Scrollbar=none BoldAsBright=Yes

保存后，关闭所有 Git Bash 窗口，重新打开一个。测试：

• 输入echo "你好，世界 🌍"—— 应正常显示中文和 emoji；
• 用鼠标选中一段文字，按 Ctrl+Shift+C 复制，再按 Ctrl+Shift+V 粘贴 —— 应成功，且粘贴内容无多余换行或空格；
• 输入ls，查看中文文件名是否清晰可读。

实操心得：FontHeight=11是经过 27 英寸 4K 屏实测的最佳值。太小看不清，太大占屏。OpaqueWhenFocused=Yes关键！否则窗口失焦时背景变透明，和桌面图标重叠，极其干扰。CtrlShiftC/V是唯一推荐组合，Windows 原生 Ctrl+C/V 在终端里会被解释为中断信号（SIGINT），导致正在运行的ping或tail直接退出。

3.3 配置 .bashrc：构建健壮的 Shell 运行时

用编辑器打开C:\Users\YourName\.bashrc，删除所有注释行（# 开头），保留原始结构，然后在文件末尾追加以下区块（严格按顺序）：

区块一：PATH 与基础变量

# 【强制】重置 PATH，确保 /usr/bin 优先 export PATH="/usr/bin:/bin:/usr/local/bin:$PATH" # 【推荐】设置默认编辑器，避免 git commit 弹出 vi export EDITOR="notepad.exe" # 【可选】设置代理（如公司内网需走 HTTP 代理） # export http_proxy="http://proxy.company.com:8080" # export https_proxy="http://proxy.company.com:8080"

区块二：Shell 行为优化

# 启用关键 shopt 选项 shopt -s globstar autocd direxpand # 历史记录增强 export HISTSIZE=10000 export HISTFILESIZE=20000 export HISTCONTROL="ignoredups:ignorespace" bind '"\C-p": history-search-backward' bind '"\C-n": history-search-forward' # 【重要】禁用 Windows 路径自动转换（防止 /c/Users → C:/Users） export MSYS_NO_PATHCONV=1

解释：MSYS_NO_PATHCONV=1是 Git Bash 2.30+ 版本新增的救命开关。不加它，curl -o /c/temp/file.zip会被自动转成C:\temp\file.zip，但某些工具（如wget）不认这种格式，报错No such file or directory。加了它，路径保持 Unix 风格，所有工具行为一致。

区块三：别名与函数

# 实用别名 alias ll='ls -alF --color=auto' alias la='ls -A --color=auto' alias l='ls -CF --color=auto' alias gs='git status -s' alias ga='git add' alias gco='git checkout' alias gb='git branch' alias gd='git diff' alias glog='git log --oneline --graph --all' # 快速导航 alias ...='cd ../..' alias ....='cd ../../..' alias .....='cd ../../../..' # 函数：安全删除（带确认） rmf() { if [ $# -eq 0 ]; then echo "Usage: rmf <file...>" return 1 fi echo "About to remove: $*" read -p "Confirm? (y/N) " -n 1 -r echo if [[ $REPLY =~ ^[Yy]$ ]]; then rm -rf "$@" else echo "Cancelled." fi }

区块四：Git 补全与提示符

# 加载 Git 补全（需提前下载 git-completion.bash） if [ -f ~/.git-completion.bash ]; then source ~/.git-completion.bash fi # 精简提示符 PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\] \[\033[01;33m\]\$(__git_ps1 "(%s)")\[\033[00m\]\$ '

保存文件，在当前终端执行source ~/.bashrc使配置立即生效（不用重启）。测试：

• 输入ll—— 应列出详细文件信息，中文名正常；
• 输入gs—— 应显示 Git 状态缩写；
• 输入git st<Tab>—— 应自动补全为git status；
• 进入一个 Git 仓库，输入git checkout dev，再看提示符 —— 应显示(dev)。

3.4 配置 .bash_profile：SSH 密钥一次加载

打开C:\Users\YourName\.bash_profile，在文件末尾添加：

# SSH agent 自动启动（仅首次登录执行） if [ -z "$SSH_AUTH_SOCK" ]; then eval $(ssh-agent -s) # 加载默认密钥（假设私钥在 ~/.ssh/id_rsa） ssh-add ~/.ssh/id_rsa 2>/dev/null # 如有其他密钥，可追加 ssh-add ~/.ssh/id_ed25519 fi

保存后，关闭所有 Git Bash 窗口，重新打开一个。执行ssh-add -l，应看到类似：

2048 SHA256:xxx user@host (RSA)

表示密钥已加载。此时git push到 GitHub/GitLab 将不再提示输入密码。

注意事项：ssh-add命令的2>/dev/null是为了屏蔽“Identity added”提示，让启动更安静。如果密钥有密码，首次执行仍需输入一次，之后 session 内永久有效。密钥文件权限必须是600（chmod 600 ~/.ssh/id_rsa），否则 ssh-add 会拒绝加载。

4. 常见问题与排查技巧实录

配置过程中，90% 的问题源于“以为改了，其实没生效”或“改了 A 文件，实际加载的是 B 文件”。以下是我在客户现场、团队分享中高频遇到的 7 类问题，附带真实排查路径和解决方案。

4.1 中文乱码：文件名显示为?????.txt，echo "中文"输出方块

现象：ls列出的中文文件名全是问号，cat README.md里中文变成乱码。排查路径：

1. 先确认 mintty 编码：右键 Git Bash 窗口标题栏 → Options → Text → Charset 应为UTF-8，Locale 应为en_US.UTF-8。如果不是，改完重启。
2. 再确认 Bash 编码：在终端输入locale，输出应类似：

   LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" ...

   如果LANG是C或POSIX，说明.bashrc里没设置。在.bashrc开头加：

   export LANG=en_US.UTF-8 export LC_ALL=en_US.UTF-8

3. 最后检查文件本身：用file -i filename.txt查看文件编码。如果是iso-8859-1，需用iconv -f iso-8859-1 -t utf-8 filename.txt > new.txt转换。

根本原因：Windows 文件系统用 UTF-16 存储文件名，Git Bash 通过 MSYS2 层转换为 UTF-8。若任一环节（mintty、Bash、文件）编码不统一，转换链断裂，必然乱码。

4.2cp: cannot stat '11.txt': no such file or directory：明明文件存在却找不到

现象：ls能看到11.txt，但cp 11.txt backup/报错。排查路径：

1. 检查当前路径：输入pwd，确认是否在目标文件所在目录。Git Bash 的pwd显示/c/Users/name/project，而 Windows 资源管理器地址栏显示C:\Users\name\project，两者等价，但新手常误以为路径不同。
2. 检查文件名大小写：Windows 文件系统不区分大小写，但 Git Bash 的cp命令区分。11.TXT和11.txt是两个文件。用ls -la看真实文件名。
3. 检查MSYS_NO_PATHCONV：如果未设export MSYS_NO_PATHCONV=1，且路径含 Windows 风格（如C:\temp\11.txt），Git Bash 会尝试转换路径，可能失败。一律用/c/temp/11.txt格式。

实操心得：永远用ls确认文件存在，再用cp。不要凭记忆打文件名。cp命令支持 Tab 补全，输入cp 1<Tab>，自动补全为cp 11.txt，杜绝手误。

4.3 Ctrl+V 粘贴失效，或粘贴后命令直接执行

现象：复制一段命令git clone https://...，按 Ctrl+V，光标不动或命令直接运行。排查路径：

1. 确认 mintty 剪贴板设置：Options → Keys → Copy and paste → “Use Ctrl+Shift+C/V as copy/paste” 必须勾选。这是唯一正确组合。
2. 检查是否启用了“Quick Edit Mode”：右键窗口标题栏 → Options → Mouse → “Quick Edit Mode”必须取消勾选。此模式下，鼠标左键选中即复制，右键即粘贴，与 Ctrl+Shift+V 冲突。
3. 测试纯文本粘贴：复制一段纯英文（如hello world），Ctrl+Shift+V 粘贴。如果成功，说明是特殊字符问题（如复制自网页的不可见 Unicode 字符）。

避坑技巧：粘贴前，先按Ctrl+A全选当前行，再Ctrl+Shift+V。这样即使粘贴内容带换行，也只替换当前行，不会触发多行执行。

4.4git status显示乱码，或git log图形化失败

现象：git status中中文文件名显示为"\344\270\200\345\217\245"，git log --graph报错fatal: bad config variable 'core.pager' in file。排查路径：

1. 检查 Git 全局配置：git config --global core.quotepath false。此设置让 Git 用原生路径显示，而非转义字符串。
2. 检查 Git pager：git config --global core.pager "less -R"。-R参数让 less 支持颜色，否则git log --color无效。
3. 检查.bashrc中git-completion.bash是否正确加载：执行type _git_status，应返回git_status is a shell function。如果报not found，说明补全文件路径错误或未 source。

经验总结：Git 的中文支持是三层嵌套：Windows 文件系统 → Git Bash 转换 → Git 自身解析。core.quotepath false是最后一环的开关，必须开。

4.5 新开终端不加载.bashrc，配置全部失效

现象：修改.bashrc后，新开 Git Bash 窗口，ll命令报command not found。排查路径：

1. 确认文件位置：ls -la ~，检查.bashrc是否真在C:\Users\YourName\下，且文件名是.bashrc（不是.bashrc.txt）。
2. 检查加载日志：在终端输入bash -x -l，它会以 debug 模式启动，并打印所有加载的文件。观察是否执行了source ~/.bashrc。
3. 检查.bash_profile是否覆盖了加载：如果.bash_profile里有source ~/.bashrc，但写在了exit之后，会导致跳过。确保source ~/.bashrc在.bash_profile文件末尾，且前面无exit。

终极方案：在.bash_profile末尾强制加载：

# 确保 .bashrc 总是被加载 if [ -f ~/.bashrc ]; then source ~/.bashrc fi

4.6ssh-add失败：Could not open a connection to your authentication agent

现象：执行ssh-add ~/.ssh/id_rsa报错Could not open a connection...。排查路径：

1. 检查SSH_AUTH_SOCK是否设置：echo $SSH_AUTH_SOCK。如果为空，说明 ssh-agent 未启动。
2. 手动启动 agent：eval $(ssh-agent -s)，再ssh-add。如果成功，说明.bash_profile里的自动启动逻辑没触发。
3. 检查.bash_profile是否被加载：bash -l -c 'echo $SSH_AUTH_SOCK'。如果为空，说明.bash_profile未执行。Git Bash 默认启动的是 login shell，但某些快捷方式可能启动 non-login shell。右键 Git Bash 快捷方式 → Properties → Target，确保结尾是--login（如"C:\Program Files\Git\git-bash.exe" --login）。

安全提醒：ssh-add加载的密钥在 agent 进程生命周期内有效。关闭所有 Git Bash 窗口后，agent 进程结束，密钥自动卸载，无需担心泄露。

4.7 终端启动慢：打开 Git Bash 要等 5 秒以上

现象：点击图标后，黑窗口出现，但命令提示符user@PC $要等很久才出现。排查路径：

1. 检查.bashrc中是否有耗时操作：注释掉所有source行，只留 PATH 设置，重启测试。如果变快，说明某个 sourced 文件（如git-completion.bash）过大或有网络请求。
2. 检查 DNS 解析：.bashrc中是否有curl或ping命令？Git Bash 启动时会阻塞等待网络超时。移除所有网络相关初始化。
3. 检查杀毒软件：火绒、360 等会扫描bash.exe启动过程。临时禁用，测试速度。如确认是杀软，将C:\Program Files\Git\加入白名单。

优化方案：git-completion.bash有 2000+ 行，加载慢。可将其精简，只保留git相关补全，删掉svn、hg等无关函数，体积减半，启动提速 3 秒。

5. 进阶技巧：让 Git Bash 成为你的第二操作系统

配置完成只是起点。真正的高效，来自把 Git Bash 当作一个可编程的工作台，而非命令行工具。以下是三个我每天都在用、但极少被提及的进阶技巧。

5.1 用find+xargs批量处理文件，替代资源管理器笨重操作

Windows 资源管理器批量重命名、替换文本、修改时间戳，要么没功能，要么要装第三方软件。Git Bash 一行命令搞定：

• 批量重命名：把所有IMG_*.jpg改为photo_001.jpg：

  i=1; find . -name "IMG_*.jpg" | while read f; do mv "$f" "$(dirname "$f")/photo_$(printf "%03d" $i).jpg"; ((i++)); done

• 批量替换文本：在所有.txt文件中，把oldtext替换为newtext：

  find . -name "*.txt" -exec sed -i 's/oldtext/newtext/g' {} \;

• 批量修改时间戳：把某目录下所有文件的修改时间设为今天：

  find /c/Users/name/docs -type f -exec touch {} \;

原理：find是 Unix 世界的瑞士军刀，-exec让它对每个匹配文件执行命令。sed -i直接编辑文件，touch更新时间戳。这些操作在 Windows 上需要 PowerShell 脚本，语法复杂且跨平台性差。

5.2 用tmux实现终端复用，告别几十个标签页

“终端复用”不是指 Tabby 或 Windows Terminal 的多标签，而是指在一个窗口里，分屏、切换、会话保持。tmux是终极方案：

1. 安装：Git Bash 自带tmux，无需额外安装。
2. 启动会话：tmux new -s work（创建名为work的会话）。
3. 分屏：Ctrl+b %（左右分）、Ctrl+b "（上下分）。
4. 切换窗格：Ctrl+b o（循环切换）。
5. 分离会话：Ctrl+b d（窗口关闭，会话后台运行）。
6. 重连会话：tmux attach -t work。

实战场景：我常开一个work会话，左屏vim code.py，右屏python code.py实时调试，上屏git status监控，下屏htop查看资源。下班前Ctrl+b d，第二天tmux attach，所有状态原样恢复。比任何 IDE 的终端都稳。

5.3 用curl+jq构建轻量 API 客户端，替代 Postman

Postman 重、占内存、启动慢。Git Bash 里，curl+jq就是命令行 Postman：

• GET 请求：curl -s "https://api.github.com/users/octocat" | jq '.login, .public_repos'
• POST 请求（JSON）：curl -X POST -H "Content-Type: application/json" -d '{"name":"test"}' https://httpbin.org/post | jq '.json'
• 带 Token 认证：curl -H "Authorization: token YOUR_TOKEN" https://api.github.com/user/repos | jq '.[] | {name, private}'

关键：-s静默模式，-H设置 Header，-d发送数据，jq解析 JSON。jq是 JSON 专用处理器，比grep精准百倍。安装jq：从 https://stedolan.github.io/jq/download/ 下载jq.exe，放入/usr/bin/目录即可。

这些技巧，没有一个是“炫技”，而是把 Git Bash 从“命令行”升级为“工作流引擎”。它不取代 Visual Studio 或 PyCharm，但它让你在 IDE 之外，拥有一套零依赖、秒启动、可脚本化的生产力底座。十年前，我靠它在客户现场 3 分钟修复一个部署脚本；今天，我靠它每天自动化 20 个重复操作。配置的终点，不是让终端看起来漂亮，而是让它成为你手指延伸出去的、最自然的一部分。