先讲一个我遇到过的真实场景：某次团队调整了远程仓库的访问权限，我把本地git仓库的remote地址从http换成了新的https地址，自以为万事大吉。结果push的时候，git既不报401，也没有像往常一样弹窗让我输入密码，而是直接推送成功。我盯着终端愣了十几秒，才反应过来——旧密码被git悄悄存到某个地方了。折腾了大半天，最终发现元凶就是.git-credentials和credential.helper这两兄弟。
今天这篇文章，就把我踩过的坑掰开揉碎讲清楚：git删除密钥（删除本地密钥、删除密码、.git-credentials）的完整实操，以及如何用git config --global --unset credential.helper真正取消自动保存密码。文中的方法我在Windows、macOS、Linux上都实测过，照着做就完事。
1. 为什么Git会"记住"你的密码：凭据存储机制解析
很多人的第一反应是"Git不是每次都会让我输密码吗？"其实这取决于你安装Git时选的选项、以及你的操作系统。Git本身不算一个"密码保险箱"，但它提供了一套叫credential helper的机制，允许第三方工具或文件替你保管凭据。你以为是"没保存"，其实它只是藏得比较深而已。
1.1 Git的四种credential helper：你遇到的到底是哪一种
Git的凭据助手（credential helper）本质上是一个外部命令，它负责"存"和"取"你的用户名密码。Git默认不启用任何helper，但很多安装包（尤其是Windows下的Git for Windows）会默认帮你带上。
| Helper 名称 | 典型配置值 | 存储位置 | 适用场景 |
|---|---|---|---|
| cache | cache | 内存，默认15分钟后过期 | 临时记住，不需要持久化 |
| store | store | 明文文件~/.git-credentials | 最原始，但密码是明文，不安全 |
| manager | manager/manager-core | Windows凭据管理器 / macOS钥匙串 | 图形化界面管理，安全度较高 |
| 自定义 | 指向脚本路径 | 取决于脚本 | 企业或高级用户定制 |
store模式最坑人，因为它直接把明文写进用户主目录下的.git-credentials文件里。很多人不知道自己开启了这个，结果一次push之后，密码就裸奔在硬盘上。manager模式虽然不会明文写进.git-credentials，但你把系统凭据管理器里的条目删掉之后，Git会重新弹窗问你密码，问完又会写回去——如果你不知道要同时取消helper配置，就会陷入"删了又来，来了又删"的循环。
1.2 不同操作系统的默认行为差异
- Windows：Git for Windows 2.29+ 默认启用
manager，实际调用的就是 Windows 凭据管理器（Credential Manager）。密码会保存在系统级的"Windows凭据"里，你可以通过控制面板找到它们，但藏得很深。 - macOS：一般会用
osxkeychainhelper，密码存在登录钥匙串里。钥匙串里一堆条目，很难直接看出来哪个是Git的。 - Linux：很多发行版默认不带helper，你输密码就是每次输入；但也有人在教程引导下配置了
store，导致/home/用户名/.git-credentials里存了明文。
这些默认行为直接决定了你后续需要走哪条清理路线——不是一条命令走天下，得先看清楚自己踩的到底是哪一种坑。
2. 如何查看当前生效的凭据配置：定位问题源头
在动手删除任何东西之前，先搞清楚当前Git到底配置了什么。这一步花不了三分钟，但能帮你少走大量弯路。我见过太多人一上来就rm .git-credentials，结果根本没删除干净，原因就在于他真正用的是Windows凭据管理器，而不是这个文件。
2.1 检查全局与系统配置的三板斧
Git配置有三个层级，优先级从高到低分别是：局部（local）、全局（global）、系统（system）。查询时用git config --list会合并展示所有层级。
# 查看所有配置（含层级信息） git config --list --show-origin # 只看全局配置 git config --global --list # 只看系统配置（可能需要管理员权限） git config --system --list执行git config --list --show-origin时，每条配置都会带上来源文件路径，比如C:/Program Files/Git/etc/gitconfig或C:/Users/你的用户名/.gitconfig。如果看到类似credential.helper=manager或credential.helper=store的行，恭喜，问题根源找到了。
2.2 识别凭据实际存放在哪里：配置文件与存储文件解析
搞清楚helper设置后，还要确认实际凭据存在哪。不同helper对应不同位置：
- 如果配置是
credential.helper=store，凭据文件路径固定为~/.git-credentials（Windows下就是C:\Users\用户名\.git-credentials）。这个文件每一行是一个URL，格式类似https://用户名:密码@gitee.com。 - 如果配置是
credential.helper=manager或manager-core，那你需要去操作系统的"凭据管理器"或"钥匙串访问"里找，Git不会生成独立文件。 - 如果配置是
credential.helper=cache，密钥只存在内存里，重启电脑或等15分钟就自动没了，不用清理。
顺带说一句，很多人会把.git-credentials当成是"仓库里的文件"，其实它固定在你用户主目录下，每个仓库配置不同remote地址时，都可能往这个文件里追加新记录。
2.3 实操：用命令确认当前helper
# 检查全局是否有credential.helper git config --global --get credential.helper # 检查系统级是否有 git config --system --get credential.helper # 检查当前仓库局部是否有 git config --local --get credential.helper如果命令返回空，说明当前层级没设置；如果返回store或manager，就按对应的方式去清理。这里要注意，三条命令都要跑一遍，因为系统级配置（通常由Git安装程序写入）优先级低于全局，但同样会被Git使用。我记得有一次排查半天，发现是系统级配了store，全局和局部都是空的，当时真的想骂人。
3. 彻底删除已保存的本地密钥和密码：分场景操作
确认完存储位置，接下来就是真正的"git删除密钥"实操。我按照最常见的三种场景，分别给出对应解法。不要跳过，因为你可能同时踩了多个坑。
3.1 删除 .git-credentials 文件中的明文记录
首先看文件里存了什么：
cat ~/.git-credentials如果确认是要清除的记录，直接删除该文件即可：
rm ~/.git-credentialsWindows下如果是用cmd，就是：
del %USERPROFILE%\.git-credentials这个文件删除后，Git在下次需要认证时会重新走提示流程，不会导致你的仓库损坏。不过注意，如果你在文件里存了多个站点的密码，删整个文件等于全部删除。如果你只想删其中某一条记录，可以用文本编辑器打开文件，单独删除对应行，保存后再改回文件名。我一般不会这么干，因为文件名不含扩展名，很容易被某些编辑器识别为"无类型文件"，建议用VS Code或Notepad++打开，别用记事本（编码问题可能会搞出UTF-8 BOM头，导致Git解析出错）。
3.2 清除Windows凭据管理器中的Git条目
如果你的helper是manager，那么删除.git-credentials没有任何作用，因为真正的凭据在Windows的系统保险箱里。打开方式：
- 键盘按
Win + S，输入"凭据管理器"（或credential manager）并回车。 - 选择"Windows凭据"（不是Web凭据）。
- 在列表中找到以
git:开头的条目，例如git:https://gitee.com。 - 点击展开，选择"删除"。
有同学会问，能不能用命令行删？可以，但不推荐手打，除非你写PowerShell脚本。这里给一个常用的cmd方式：
cmdkey /list | findstr /i "git" cmdkey /delete:git:https://gitee.comcmdkey /delete后面需要跟着完整的凭据名称。先用/list查看所有条目，确认目标再删。这样比鼠标点半天快很多。但要注意，如果Windows凭据管理器里同时存在多个git:前缀条目，需要逐一删除。删完之后，可以再执行git push验证，这次应该会弹出认证窗口。
3.3 清除macOS钥匙串中的项
macOS用户如果用了osxkeychain，打开"钥匙串访问"（Keychain Access），在"登录"钥匙串里搜索git，会找到类似https://github.com或git:https://gitee.com的互联网密码条目。右键删除，或选中后按删除键。命令行方式也支持：
git credential-osxkeychain erase这个命令会进入交互模式，输入protocol=https、host=github.com，然后按两下回车（一个空行结束输入），再输入username=你的用户名，再按两下回车。实测可以删掉对应条目。但说实话，图形界面更快，没必要记这条命令。
3.4 删除Linux/全局store文件
Linux上如果配置了store，同样直接删除~/.git-credentials。如果配置的是cache，不用管，自动过期。还有一种情况是你把helper指向了一个自定义脚本，那清理方式取决于脚本实现，通常是删除脚本创建的状态文件。这部分比较罕见，但如果你像我一样喜欢魔改配置，建议先看看脚本内容再动手。
4. 取消自动保存密码：git config --global --unset 的正确用法与变体
删除已经存在的密钥只是治标，真正治本的是修改Git配置，让它以后不要再自动保存。标题里提到的git config --global --unset credential.helper就是干这个的，但这里面的坑比想象中多。
4.1 从全局配置中移除 credential.helper
先查后删，避免误删其他配置：
git config --global --unset credential.helper这条命令会移除全局层级的credential.helper配置。如果全局层级没有这项设置，命令会返回错误码5（stdout会打印错误），这很正常，不用慌。你可以再执行一次验证：
git config --global --get credential.helper如果返回空，说明全局已经清干净。
但注意，--unset只删一个"键"的第一个值。如果全局配置里出现了多个credential.helper（比如有人既写了helper=store又写了helper=manager），--unset只会删除第一个。此时需要：
git config --global --unset-all credential.helper--unset-all会把所有同名配置一起删除。我建议在清理时直接使用--unset-all，避免残留。
4.2 系统级配置的坑：为什么你unset之后还是自动保存
这是最容易让人崩溃的点：你执行了git config --global --unset credential.helper，甚至验证了全局配置为空，但push时git还是弹出"记住密码"的勾选框，或者仍然用之前的密码直接通过。这往往是因为系统级配置里还保留着同一个helper。
- Git安装程序（尤其是Windows版）默认会在系统级配置写入
credential.helper=manager。 - 系统级配置的文件路径通常在
C:/Program Files/Git/etc/gitconfig（Windows）或/etc/gitconfig（Linux/macOS）。 - 全局配置优先级高于系统级，但你unset的只是全局，没删系统级的，所以Git会继续使用系统级的helper。
解决方法：
git config --system --unset-all credential.helper这条命令可能需要管理员权限。Windows下请以管理员身份运行Git Bash或PowerShell；macOS下可能需要sudo：
sudo git config --system --unset-all credential.helper执行后，再通过git config --list --show-origin确认整个配置链路上都没有helper了。另一个坑是仓库局部配置：
git config --local --unset-all credential.helper有些仓库自己在.git/config里写入了helper，这同样会影响当前仓库的行为。所以正确做法是三层都查一遍，三层都清掉。
4.3 不要瞎设"假配置"：常见的错误思路
我在论坛上经常看到有人提出"把helper设置成一个不存在的命令，这样Git就弹不出保存密码的框了"，比如：
git config --global credential.helper ""或者：
git config --global credential.helper none这种做法非常坑。把helper设为空字符串，在部分Git版本中会被解释为"忽略该配置"，但有些老版本会报错。设成none则会让Git尝试去执行一个叫none的命令，每次认证都会报"无法找到none"，然后直接认证失败。所以别想着绕，直接unset才是正道。
4.4 如果不想删配置，只想让Git永远不保存某个特定仓库的密码
如果你只需要针对某一个仓库关闭自动保存，不需要动用全局配置。进入仓库目录，执行：
git config --local --unset-all credential.helper这样只影响当前仓库，不影响其他仓库。这个方式适合那种"只在这个项目上需要临时认证，其他项目还希望保留自动保存"的场景，算是精细化控制的技巧。
5. 常见问题与排查技巧实录
清理凭据和取消自动保存不是一次能搞定的，总会遇到各种奇奇怪怪的事。下面几类问题是我在后台收到频率最高的，逐一讲清楚。
5.1 为什么取消配置后仍然弹窗/仍然能推送？
分两种情况判断：
- 仍然弹窗：说明helper没有完全移除。按上文检查三个层级，注意系统级配置。
- 仍然能推送（不弹窗也不输密码）：说明凭据仍然存在于系统凭据库中，比如Windows凭据管理器、macOS钥匙串、或遗留的
.git-credentials文件。你apt-get的helper只是"存/取"机制，而那些旧记录还在存储区里。即使配置文件已unset，Git在认证时会先试图从已知凭据存储中找，如果找到了，就不会触发重新输入。因此一定要"先删记录、再取消配置"。
一个特殊场景：你在同一台机器上有两个账号，一个全局凭据是A用户，但某个仓库配置了B用户的token，结果push时一直用A的凭据失败。这时除了清凭据，还要确认remote URL中是否已经带了账号信息，比如https://用户名@github.com/...这样的地址，Git会优先使用URL中的用户名，配合存储的密码进行认证。
5.2 删除了 .git-credentials 文件但密码还在？
多半是因为你同时启用了 Windows凭据管理器或钥匙串。store和manager可以同时存在吗？可以。如果你全局配置是manager，但系统级是store，那么Git会依次尝试。.git-credentials删了之后，系统凭据库里还有一份，于是就像打地鼠一样，删了一处另一处又顶上。
解决办法很简单：git config --list --show-origin看所有helper来源，把所有helper全部unset完全，然后清理所有对应的存储位置。具体就是Windows凭据管理器 +.git-credentials+ 钥匙串，三者都过一遍。
5.3 使用Personal Access Token时最容易踩的坑
GitHub、Gitee、GitLab现在都不支持直接用账户密码做HTTPS认证了，而是用Personal Access Token（PAT）代替密码。这个token在推送时会被当作密码。问题来了：很多用户把token保存到.git-credentials，然后token过期了，旧token还留在文件里，导致git一直推送失败，但git却总是自动用旧token，甚至不弹窗让你更换。
所以清理凭据后，如果你未来还会用到HTTPS方式，建议下次认证时输入新token时，不要勾选"记住密码"。在Windows的Git凭据管理器中，如果弹窗询问，直接取消即可。如果已经保存了旧token，按照第一节的方式删除对应条目。
5.4 一键脚本：清空当前用户的所有Git凭据（谨慎使用）
我自己写过一个PowerShell脚本，用于快速清理当前用户下的所有常见Git凭据存储位置。放出来供参考，但使用前请确认你知道自己在干什么：
# 以管理员身份运行 PowerShell（Windows） # 1. 清理 .git-credentials if (Test-Path "$HOME\.git-credentials") { Remove-Item "$HOME\.git-credentials" -Force Write-Host "已删除 .git-credentials" } # 2. 清理 Windows 凭据管理器中所有 git: 开头的条目 cmdkey /list | ForEach-Object { if ($_ -match "^ 目标:\s*(git:.*)$") { $target = $matches[1] cmdkey /delete:$target Write-Host "已删除凭据: $target" } } # 3. 清理 Git 配置中的 helper git config --global --unset-all credential.helper git config --system --unset-all credential.helper Write-Host "已清除 Git 全局和系统级的 credential.helper 配置"在Linux/macOS下，可以写成bash版本：
#!/bin/bash rm -f ~/.git-credentials git config --global --unset-all credential.helper git config --system --unset-all credential.helper # macOS 可再执行钥匙串清理，Linux 一般不用。脚本只是辅助，日志里如果有essentials看不到的东西，还是要人工核对。
5.5 提一个冷门但重要的细节：credential cache过期时间
有些配置里会写credential.helper=cache --timeout=3600，意思是密钥缓存一小时。这种配置的存储位置不是文件，所以删除.git-credentials没用。如果你想让cache模式不持久化，可以设置超时时间很短，比如：
git config --global credential.helper "cache --timeout=60"这是"不想让密码长期保存在磁盘、但开发时又不想反复输入"的一种折中方案。不过，这不属于"取消自动保存"，最多算"短时间自动保存"。我个人已经不再使用这种模式，因为SSH密钥才是更彻底的办法。
6. 换用SSH密钥：真正远离密码保存问题
如果你烦透了HTTPS下凭据管理的这些问题，建议直接切换为SSH方式。SSH密钥也存在本地，但它私钥有独立的权限管理，且可以设置口令（passphrase），配合ssh-agent使用，体验并不差。下面简单说一说切换思路，但不展开全流程。
远程仓库地址从HTTPS换成SSH：
git remote set-url origin git@gitee.com:用户名/仓库名.git然后本地生成SSH密钥并配置到远程平台：
ssh-keygen -t ed25519 -C "你的邮箱"生成的公钥（.pub文件）内容配置到Git平台的SSH keys页面。私钥保留在本地，推送时只要ssh-agent加载过私钥，就不再需要密码。这样彻底绕开了credential.helper这个话题，也就不用天天担心.git-credentials泄露了。
我已经把个人电脑上所有仓库都迁到了SSH模式，输密码的频率降低了90%。唯一的代价是新电脑第一次克隆时需要把私钥拷贝过去并配置ssh-agent，但相比维护一堆HTTPS凭据，这成本完全值得。
最后再分享一个我自己的习惯：无论用哪种方式，我每周都会例行检查一遍本机的Git配置和凭据存储。用一个命令就能看到所有配置来源：
git config --list --show-origin如果看到任何credential.helper相关配置，就停下来想想是否真的需要它，不需要就立刻unset。这套方法帮我避免了好几次因为旧凭据导致的上不了线事故，希望你也能用上。
