1. 为什么“改个名字”这件事比想象中重要刚入行那会儿我对 Git 的认知就是add、commit、push三件套觉得只要代码能推上去其他都是花架子。直到有一次帮某实验室整理一个开源项目的提交记录才发现提交历史里赫然写着rootlocalhost和一串乱码邮箱整个贡献者列表看起来像一台没人管的服务器在自言自语。那一刻我才意识到Git 里的“用户名”和“邮箱”不是随便填填的装饰品它是你每一次提交的身份证写错了、写乱了后面想改就得动历史麻烦程度直接翻倍。这篇内容就是围绕git 常用命令中修改用户名作者以及重置 git 账号密码这条主线展开的。说白了它解决的是三类很具体的问题第一你本地配置的提交作者信息写错了或者换了新身份想让后续提交用新名字第二你已经提交了一堆记录想把历史里的旧名字批量替换掉第三你的账号凭据过期或者换账号了推送时一直报认证失败需要把本地缓存的密码清掉重新登录。适合谁看我觉得三类人最需要刚配好 Git 环境还没搞明白user.name和user.email到底影响什么的新手接手了别人电脑或者共用机器、发现提交作者不是自己的开发者还有那些换了邮箱、换了账号结果push一直弹认证错误的同学。不管你用的是命令行、图形客户端还是 IDE 内置的 Git底层逻辑都一样看完你就能自己动手把这些问题一次性理清楚。我先把结论摆在这儿Git 的作者信息分“全局配置”和“仓库级配置”两层改的时候要搞清楚改哪一层已经产生的历史提交不会因为你改了配置就自动变需要额外手段重写而账号密码的“重置”本质上不是改 Git 配置而是清理系统或客户端里缓存的凭据。这三件事经常被混为一谈下面我一个个拆开讲。2. 先搞懂 Git 的作者信息到底存在哪2.1 user.name 和 user.email 的真实作用很多人以为user.name是登录 Git 服务的账号名这是个特别常见的误解。实际上user.name和user.email只是提交元数据它们会被写进每一个 commit 对象里用来标记“这次提交是谁做的”。它跟你登录远程仓库用的账号密码完全是两码事。你可以把user.name理解成你在快递单上写的寄件人姓名而登录凭据是你进快递站的门禁卡两者互不干涉。这也解释了一个现象为什么有些人user.name填的是中文昵称照样能正常推送代码。因为远程服务校验的是你的凭据而不是你 commit 里的名字。但反过来说如果你在某个开源平台贡献代码平台是靠user.email来把提交关联到你的账户上的邮箱填错了你的贡献就不会显示在你的主页上。所以邮箱这一项比名字更值得认真对待。查看当前配置的命令很简单git config --list如果只想看作者相关的两项git config user.name git config user.email注意直接这样查出来的是当前生效的值它可能是全局的也可能是当前仓库覆盖过的。想看得更清楚可以加上--show-origin参数它会告诉你这个值到底来自哪个配置文件git config --show-origin --get user.name输出里会带上文件路径比如全局的~/.gitconfig或者仓库内的.git/config。这个技巧在排查“为什么我改了全局配置但提交还是旧名字”时特别有用因为大概率是仓库级配置把全局的覆盖了。2.2 全局配置与仓库级配置的优先级Git 的配置是分层覆盖的优先级从高到低大致是仓库级.git/config 全局级~/.gitconfig 系统级/etc/gitconfig。也就是说如果某个仓库里单独设了user.name那么全局配置在这个仓库里就不生效了。这个设计的好处是灵活你可以全局配一个默认身份然后在公司项目仓库里单独配成工作邮箱在个人项目里用私人邮箱。但坏处是容易让人迷惑尤其是接手别人仓库的时候发现提交作者怎么改都不对八成就是仓库级配置在作祟。设置全局身份git config --global user.name 你的名字 git config --global user.email 你的邮箱example.com只对当前仓库设置git config user.name 你的名字 git config user.email 你的邮箱example.com区别就在于有没有--global。我个人的习惯是全局配一套个人身份然后每进一个公司或组织的仓库第一件事就是检查并覆盖成对应身份。这样能避免把私人邮箱写进工作提交里也能避免工作邮箱出现在个人开源项目里。提示设置完之后一定要用git config --show-origin --get user.email复核一遍确认生效的是你想要的那一层别嫌麻烦这一步能省掉后面重写历史的痛苦。2.3 配置文件的直接编辑方式除了命令行你也可以直接编辑配置文件。全局配置一般在用户主目录下的.gitconfig仓库级配置在仓库的.git/config。用任意文本编辑器打开就能改格式是类似 ini 的键值对[user] name 你的名字 email 你的邮箱example.com直接编辑的好处是能一眼看到所有配置项适合批量调整。但要注意别把格式写坏缩进和大小写虽然不严格但[user]这个段落头不能少。改完之后同样用git config命令验证一下确保 Git 能正确解析。我踩过的一个坑是在 Windows 上编辑.gitconfig时用了带 BOM 的编码结果 Git 读取时报了一堆莫名其妙的错。后来统一用 UTF-8 无 BOM 保存就没事了。这种细节平时没人提但真遇到的时候能折腾半天。3. 修改用户名和邮箱的完整实操3.1 只改后续提交最简单的场景如果你只是想让从现在开始的提交用新名字不关心历史记录那操作非常简单改配置就行。这也是绝大多数人真正需要的场景。第一步确认当前值git config --show-origin --get user.name git config --show-origin --get user.email第二步按需修改。如果想让所有仓库都用新身份git config --global user.name 新名字 git config --global user.email 新邮箱example.com如果只想改当前仓库git config user.name 新名字 git config user.email 新邮箱example.com第三步验证git config user.name git config user.email改完之后你下一次git commit产生的提交就会带上新信息。已经存在的历史提交不受影响这是 Git 的设计决定的——commit 一旦生成它的内容包括作者信息就被哈希锁定了改任何一个字符都会导致哈希变化进而影响后续所有提交。所以“改配置”和“改历史”是两件必须分开理解的事。这里有个细节值得说如果你在改配置之前已经git add了文件但还没 commit改完配置再 commit用的就是新身份。因为作者信息是在 commit 那一刻才写入的跟 add 无关。3.2 批量重写历史提交的作者信息现在说麻烦的部分。假设你已经提交了 50 次全用错了邮箱现在想把这 50 次的作者信息都改过来。这时候改配置已经没用了必须重写历史。最常用的工具是git filter-branch虽然官方现在更推荐git filter-repo但前者是 Git 自带的不用额外安装应急足够用。下面这条命令能把指定分支上所有提交的作者名和邮箱替换掉git filter-branch --env-filter OLD_NAME旧名字 OLD_EMAIL旧邮箱example.com NEW_NAME新名字 NEW_EMAIL新邮箱example.com if [ $GIT_COMMITTER_NAME $OLD_NAME ] || [ $GIT_COMMITTER_EMAIL $OLD_EMAIL ]; then export GIT_COMMITTER_NAME$NEW_NAME export GIT_COMMITTER_EMAIL$NEW_EMAIL fi if [ $GIT_AUTHOR_NAME $OLD_NAME ] || [ $GIT_AUTHOR_EMAIL $OLD_EMAIL ]; then export GIT_AUTHOR_NAME$NEW_NAME export GIT_AUTHOR_EMAIL$NEW_EMAIL fi --tag-name-filter cat -- --all这条命令有几个关键点必须解释清楚。--env-filter是让 Git 在每个提交上执行一段环境变量过滤脚本GIT_AUTHOR_*是原始作者信息GIT_COMMITTER_*是提交者信息两者可能不同比如你 rebase 别人的提交时。--tag-name-filter cat是让标签也跟着重写-- --all表示对所有分支和标签生效。注意filter-branch会重写提交哈希如果这个仓库已经推送到远程并且有其他人协作重写后必须强制推送而且所有协作者都得重新克隆或者做复杂的手动同步。在共享仓库上做这件事之前一定要先跟团队沟通否则会把别人的工作搞乱。执行完之后本地会生成一个备份引用refs/original/确认没问题后可以删掉它让旧对象被垃圾回收git for-each-ref --format%(refname) refs/original/ | xargs -n 1 git update-ref -d git reflog expire --expirenow --all git gc --prunenow这几步是清理残留不做的话旧提交对象还在仓库体积不会减小而且万一改错了还能靠 reflog 找回来。我一般会先做完重写、验证无误再执行清理。3.3 用 filter-repo 更优雅地重写如果你愿意装一个额外工具git filter-repo比filter-branch快得多也更安全。它需要单独安装很多包管理器里都有。用它改作者信息只需要一条命令git filter-repo --name-callback return b新名字 --email-callback return b新邮箱example.com或者更精细地只替换特定旧邮箱git filter-repo --mailmap mailmap.txt配合一个mailmap.txt文件内容格式是新名字 新邮箱example.com 旧名字 旧邮箱example.com这种方式的好处是可读性强能一次处理多个映射关系而且filter-repo默认会做很多安全检查比如拒绝在非裸仓库上直接操作、自动处理引用等。实测下来几百个提交的仓库用filter-branch要等好几分钟filter-repo几秒钟就完事。不过要注意filter-repo默认会删掉origin远程防止你误推。重写完成后需要手动加回来git remote add origin 仓库地址这个设计一开始让我有点懵后来理解了它的用意——强制你确认重写结果之后再重新关联远程避免手滑直接推上去。3.4 只改最近一次提交的作者如果只是最后一次提交写错了那完全不用大动干戈一条命令搞定git commit --amend --author新名字 新邮箱example.com --no-edit--amend是修改最近一次提交--author指定新的作者信息--no-edit表示不改提交信息。这条命令会生成一个新的提交替换掉旧的哈希会变但因为没有推送到远程所以没有任何副作用。如果最近几次都写错了可以用交互式 rebasegit rebase -i HEAD~3把要改的那几次提交前面的pick改成edit然后逐个执行git commit --amend --author... --no-edit最后git rebase --continue。这种方式适合少量提交的精确修改比全量重写安全得多。4. 重置 Git 账号密码的几种真实场景4.1 认证失败到底是谁在报错先说一个容易混淆的点git push时弹出的认证失败报错来源可能是好几个地方。有的是远程服务拒绝了你过期的令牌有的是本地凭据管理器里存的旧密码不对还有的是 SSH 密钥不匹配。所以“重置密码”之前得先判断问题出在哪一层。常见的报错信息有这么几类。如果提示Authentication failed或者invalid username or password基本是凭据问题。如果提示Permission denied (publickey)那是 SSH 密钥的问题跟密码无关。如果提示403 Forbidden可能是权限不足或者令牌过期。看清楚报错再动手能少走很多弯路。判断当前用的是 HTTPS 还是 SSH可以看远程地址git remote -v地址以https://开头就是 HTTPS 方式以git开头就是 SSH 方式。两种方式的凭据管理完全不同下面分开讲。4.2 清理 HTTPS 方式缓存的凭据HTTPS 方式下Git 通常会把你的用户名和密码或令牌交给系统的凭据管理器缓存起来这样你不用每次推送都输入。但当你换了账号或者令牌过期时这个缓存就成了绊脚石。不同系统的凭据存储位置不一样。Windows 上一般用“凭据管理器”可以在控制面板里找到“Windows 凭据”里面会有git:https://...之类的条目删掉对应的即可。macOS 上用“钥匙串访问”搜索 git 相关的条目删除。Linux 上则取决于你配置的 credential helper可能是store明文存在~/.git-credentials、cache内存缓存或者libsecret。命令行清理方式先看当前用的 helpergit config --global credential.helper如果是store直接删文件rm ~/.git-credentials如果是cache清空缓存git credential-cache exit如果是manager或manager-coreWindows 常见可以用git credential-manager erase然后按提示输入协议和主机它会删掉对应条目。更简单的办法是直接在下一次推送时让它重新弹窗git config --global --unset credential.helper git push推送时会重新要求输入凭据输入新的之后再把 helper 设回去git config --global credential.helper manager提示现在很多代码托管平台已经不支持直接用账户密码推送了必须用个人访问令牌代替密码。如果你一直提示认证失败先确认自己用的是不是令牌而不是登录密码。这是新手最容易卡住的地方。4.3 SSH 方式的密钥重置SSH 方式不涉及“密码”而是密钥对。如果你换了机器或者密钥丢了需要重新生成一对然后把公钥传到远程账户里。生成新密钥ssh-keygen -t ed25519 -C 你的邮箱example.comed25519是目前推荐的算法比老的 RSA 更短更安全。一路回车即可也可以设置一个 passphrase 增加一层保护。生成后公钥在~/.ssh/id_ed25519.pub私钥在~/.ssh/id_ed25519私钥绝对不能外传。查看公钥内容cat ~/.ssh/id_ed25519.pub把输出整段复制到远程平台的 SSH 密钥设置里。然后测试连接ssh -T git主机名如果看到欢迎信息说明配置成功。如果提示权限被拒检查~/.ssh/config里有没有针对该主机的配置以及私钥权限是不是过宽Linux/macOS 上私钥权限必须是 600否则 SSH 会拒绝使用。chmod 600 ~/.ssh/id_ed25519这个权限问题我遇到过好几次尤其是从别处拷贝密钥文件过来的时候权限默认不对SSH 直接罢工报错还不太直观排查起来费劲。4.4 多账号共存时的凭据隔离如果你同时用两个账号比如一个工作一个个人HTTPS 方式下很容易出现凭据串号的问题——推工作仓库时用了个人凭据反之亦然。解决办法是给不同主机或不同路径配置不同的凭据。一种方式是在~/.ssh/config里为 SSH 配置不同的 Host 别名各自指定不同的密钥Host work-git HostName 工作主机 User git IdentityFile ~/.ssh/id_ed25519_work Host personal-git HostName 个人主机 User git IdentityFile ~/.ssh/id_ed25519_personal然后远程地址用别名git remote set-url origin gitwork-git:组名/仓库名.gitHTTPS 方式则可以用credential.useHttpPath让凭据按路径区分git config --global credential.useHttpPath true这样同一个主机下不同路径的仓库会用不同的凭据缓存避免互相覆盖。这个配置在多账号场景下几乎是必开的我强烈建议加上。5. 常见问题与排查速查5.1 改了配置但提交还是旧名字这是最高频的问题原因几乎都是仓库级配置覆盖了全局配置。排查方法前面提过用git config --show-origin --get user.name看生效来源。如果显示的是.git/config说明这个仓库单独设过需要在这个仓库里再改一次或者把仓库级的那条删掉git config --unset user.name git config --unset user.email删掉之后就会回落到全局配置。另一个可能的原因是你在 IDE 里提交而 IDE 有自己的 Git 配置入口改的地方和命令行不是同一处。这种情况要去 IDE 的设置里找版本控制相关的配置项。5.2 重写历史后推送被拒绝重写历史会改变提交哈希远程仓库的旧历史和你本地的新历史对不上普通push会被拒绝。这时候需要强制推送git push --force-with-lease我推荐用--force-with-lease而不是--force因为前者会在推送前检查远程有没有别人的新提交如果有就拒绝避免覆盖别人的工作。--force则是无脑覆盖危险得多。如果远程有分支保护规则不允许强制推送那就只能走合并请求的方式或者联系仓库管理员临时放开。这种情况在正规团队里很常见提前沟通比硬来强。5.3 凭据清了还是提示认证失败清完本地凭据还失败可能是这几个原因令牌本身过期了需要去平台重新生成账号被限制了推送权限或者网络层有代理干扰。逐一排查先用浏览器登录平台确认账号正常再重新生成一个令牌用新令牌试一次。如果还不行检查git config --global --get http.proxy有没有设代理有的话临时取消试试。还有一种隐蔽情况某些平台的令牌区分权限范围只读令牌是不能推送的。生成令牌时一定要勾选仓库写入权限这个细节很容易被忽略。5.4 速查表问题现象可能原因解决方向提交作者是旧名字仓库级配置覆盖全局用--show-origin定位并修改对应层历史提交作者错误配置改晚了用filter-branch或filter-repo重写推送提示认证失败凭据缓存过期清理 credential helper 缓存提示 publickey 被拒SSH 密钥问题重新生成密钥并上传公钥强制推送被拒分支保护规则走合并请求或联系管理员多账号凭据串号凭据未按路径隔离开启credential.useHttpPath6. 几个我踩过的坑和私房建议第一个坑是关于filter-branch的备份。它执行后会在refs/original/下留一份原始引用很多人以为这是自动备份就放心了结果清理的时候顺手删了等发现改错了想回滚已经找不回来了。我的做法是重写之前先整个仓库复制一份或者至少打个分支标签git branch backup-before-rewrite这样即使清理了refs/original/还有分支可以兜底。多占一点磁盘空间换的是心安。第二个坑是邮箱大小写。有些平台对邮箱大小写敏感NameExample.com和nameexample.com可能被当成两个不同的贡献者。重写历史时如果只匹配了一种写法另一种就漏掉了。稳妥的做法是用filter-repo的 mailmap它能处理多种映射而且不区分大小写的匹配可以自己写脚本控制。第三个建议是关于令牌管理。别把令牌硬编码在远程地址里比如https://用户名:令牌主机/仓库.git这种写法虽然方便但令牌会明文存在.git/config里一旦仓库目录被分享或者截图令牌就泄露了。正确做法是让凭据管理器去存远程地址保持干净的https://主机/仓库.git。第四个经验是关于团队协作。任何重写历史的操作在共享仓库上都必须提前通知所有人。我见过一次因为有人偷偷 force push 重写历史导致另外几个人的本地分支全部错乱花了大半天才恢复。重写历史不是技术难题是协作问题沟通到位比命令写对更重要。最后分享一个检查提交作者的小技巧。想快速看一个仓库里都有哪些作者可以用git shortlog -sne它会按提交数排序列出所有作者和邮箱一眼就能看出有没有混入奇怪的身份。接手新仓库或者准备开源之前跑一下能提前发现不少问题。这个命令我几乎每次整理仓库都会用比一个个翻 log 高效多了。 
长河君 · 2026/10/21 23:49:11 · 阅读 1.2k Git 修改用户名与重置账号密码：配置、历史重写与凭据清理
1. 为什么“改个名字”这件事比想象中重要刚入行那会儿我对 Git 的认知就是add、commit、push三件套觉得只要代码能推上去其他都是花架子。直到有一次帮某实验室整理一个开源项目的提交记录才发现提交历史里赫然写着rootlocalhost和一串乱码邮箱整个贡献者列表看起来像一台没人管的服务器在自言自语。那一刻我才意识到Git 里的“用户名”和“邮箱”不是随便填填的装饰品它是你每一次提交的身份证写错了、写乱了后面想改就得动历史麻烦程度直接翻倍。这篇内容就是围绕git 常用命令中修改用户名作者以及重置 git 账号密码这条主线展开的。说白了它解决的是三类很具体的问题第一你本地配置的提交作者信息写错了或者换了新身份想让后续提交用新名字第二你已经提交了一堆记录想把历史里的旧名字批量替换掉第三你的账号凭据过期或者换账号了推送时一直报认证失败需要把本地缓存的密码清掉重新登录。适合谁看我觉得三类人最需要刚配好 Git 环境还没搞明白user.name和user.email到底影响什么的新手接手了别人电脑或者共用机器、发现提交作者不是自己的开发者还有那些换了邮箱、换了账号结果push一直弹认证错误的同学。不管你用的是命令行、图形客户端还是 IDE 内置的 Git底层逻辑都一样看完你就能自己动手把这些问题一次性理清楚。我先把结论摆在这儿Git 的作者信息分“全局配置”和“仓库级配置”两层改的时候要搞清楚改哪一层已经产生的历史提交不会因为你改了配置就自动变需要额外手段重写而账号密码的“重置”本质上不是改 Git 配置而是清理系统或客户端里缓存的凭据。这三件事经常被混为一谈下面我一个个拆开讲。2. 先搞懂 Git 的作者信息到底存在哪2.1 user.name 和 user.email 的真实作用很多人以为user.name是登录 Git 服务的账号名这是个特别常见的误解。实际上user.name和user.email只是提交元数据它们会被写进每一个 commit 对象里用来标记“这次提交是谁做的”。它跟你登录远程仓库用的账号密码完全是两码事。你可以把user.name理解成你在快递单上写的寄件人姓名而登录凭据是你进快递站的门禁卡两者互不干涉。这也解释了一个现象为什么有些人user.name填的是中文昵称照样能正常推送代码。因为远程服务校验的是你的凭据而不是你 commit 里的名字。但反过来说如果你在某个开源平台贡献代码平台是靠user.email来把提交关联到你的账户上的邮箱填错了你的贡献就不会显示在你的主页上。所以邮箱这一项比名字更值得认真对待。查看当前配置的命令很简单git config --list如果只想看作者相关的两项git config user.name git config user.email注意直接这样查出来的是当前生效的值它可能是全局的也可能是当前仓库覆盖过的。想看得更清楚可以加上--show-origin参数它会告诉你这个值到底来自哪个配置文件git config --show-origin --get user.name输出里会带上文件路径比如全局的~/.gitconfig或者仓库内的.git/config。这个技巧在排查“为什么我改了全局配置但提交还是旧名字”时特别有用因为大概率是仓库级配置把全局的覆盖了。2.2 全局配置与仓库级配置的优先级Git 的配置是分层覆盖的优先级从高到低大致是仓库级.git/config 全局级~/.gitconfig 系统级/etc/gitconfig。也就是说如果某个仓库里单独设了user.name那么全局配置在这个仓库里就不生效了。这个设计的好处是灵活你可以全局配一个默认身份然后在公司项目仓库里单独配成工作邮箱在个人项目里用私人邮箱。但坏处是容易让人迷惑尤其是接手别人仓库的时候发现提交作者怎么改都不对八成就是仓库级配置在作祟。设置全局身份git config --global user.name 你的名字 git config --global user.email 你的邮箱example.com只对当前仓库设置git config user.name 你的名字 git config user.email 你的邮箱example.com区别就在于有没有--global。我个人的习惯是全局配一套个人身份然后每进一个公司或组织的仓库第一件事就是检查并覆盖成对应身份。这样能避免把私人邮箱写进工作提交里也能避免工作邮箱出现在个人开源项目里。提示设置完之后一定要用git config --show-origin --get user.email复核一遍确认生效的是你想要的那一层别嫌麻烦这一步能省掉后面重写历史的痛苦。2.3 配置文件的直接编辑方式除了命令行你也可以直接编辑配置文件。全局配置一般在用户主目录下的.gitconfig仓库级配置在仓库的.git/config。用任意文本编辑器打开就能改格式是类似 ini 的键值对[user] name 你的名字 email 你的邮箱example.com直接编辑的好处是能一眼看到所有配置项适合批量调整。但要注意别把格式写坏缩进和大小写虽然不严格但[user]这个段落头不能少。改完之后同样用git config命令验证一下确保 Git 能正确解析。我踩过的一个坑是在 Windows 上编辑.gitconfig时用了带 BOM 的编码结果 Git 读取时报了一堆莫名其妙的错。后来统一用 UTF-8 无 BOM 保存就没事了。这种细节平时没人提但真遇到的时候能折腾半天。3. 修改用户名和邮箱的完整实操3.1 只改后续提交最简单的场景如果你只是想让从现在开始的提交用新名字不关心历史记录那操作非常简单改配置就行。这也是绝大多数人真正需要的场景。第一步确认当前值git config --show-origin --get user.name git config --show-origin --get user.email第二步按需修改。如果想让所有仓库都用新身份git config --global user.name 新名字 git config --global user.email 新邮箱example.com如果只想改当前仓库git config user.name 新名字 git config user.email 新邮箱example.com第三步验证git config user.name git config user.email改完之后你下一次git commit产生的提交就会带上新信息。已经存在的历史提交不受影响这是 Git 的设计决定的——commit 一旦生成它的内容包括作者信息就被哈希锁定了改任何一个字符都会导致哈希变化进而影响后续所有提交。所以“改配置”和“改历史”是两件必须分开理解的事。这里有个细节值得说如果你在改配置之前已经git add了文件但还没 commit改完配置再 commit用的就是新身份。因为作者信息是在 commit 那一刻才写入的跟 add 无关。3.2 批量重写历史提交的作者信息现在说麻烦的部分。假设你已经提交了 50 次全用错了邮箱现在想把这 50 次的作者信息都改过来。这时候改配置已经没用了必须重写历史。最常用的工具是git filter-branch虽然官方现在更推荐git filter-repo但前者是 Git 自带的不用额外安装应急足够用。下面这条命令能把指定分支上所有提交的作者名和邮箱替换掉git filter-branch --env-filter OLD_NAME旧名字 OLD_EMAIL旧邮箱example.com NEW_NAME新名字 NEW_EMAIL新邮箱example.com if [ $GIT_COMMITTER_NAME $OLD_NAME ] || [ $GIT_COMMITTER_EMAIL $OLD_EMAIL ]; then export GIT_COMMITTER_NAME$NEW_NAME export GIT_COMMITTER_EMAIL$NEW_EMAIL fi if [ $GIT_AUTHOR_NAME $OLD_NAME ] || [ $GIT_AUTHOR_EMAIL $OLD_EMAIL ]; then export GIT_AUTHOR_NAME$NEW_NAME export GIT_AUTHOR_EMAIL$NEW_EMAIL fi --tag-name-filter cat -- --all这条命令有几个关键点必须解释清楚。--env-filter是让 Git 在每个提交上执行一段环境变量过滤脚本GIT_AUTHOR_*是原始作者信息GIT_COMMITTER_*是提交者信息两者可能不同比如你 rebase 别人的提交时。--tag-name-filter cat是让标签也跟着重写-- --all表示对所有分支和标签生效。注意filter-branch会重写提交哈希如果这个仓库已经推送到远程并且有其他人协作重写后必须强制推送而且所有协作者都得重新克隆或者做复杂的手动同步。在共享仓库上做这件事之前一定要先跟团队沟通否则会把别人的工作搞乱。执行完之后本地会生成一个备份引用refs/original/确认没问题后可以删掉它让旧对象被垃圾回收git for-each-ref --format%(refname) refs/original/ | xargs -n 1 git update-ref -d git reflog expire --expirenow --all git gc --prunenow这几步是清理残留不做的话旧提交对象还在仓库体积不会减小而且万一改错了还能靠 reflog 找回来。我一般会先做完重写、验证无误再执行清理。3.3 用 filter-repo 更优雅地重写如果你愿意装一个额外工具git filter-repo比filter-branch快得多也更安全。它需要单独安装很多包管理器里都有。用它改作者信息只需要一条命令git filter-repo --name-callback return b新名字 --email-callback return b新邮箱example.com或者更精细地只替换特定旧邮箱git filter-repo --mailmap mailmap.txt配合一个mailmap.txt文件内容格式是新名字 新邮箱example.com 旧名字 旧邮箱example.com这种方式的好处是可读性强能一次处理多个映射关系而且filter-repo默认会做很多安全检查比如拒绝在非裸仓库上直接操作、自动处理引用等。实测下来几百个提交的仓库用filter-branch要等好几分钟filter-repo几秒钟就完事。不过要注意filter-repo默认会删掉origin远程防止你误推。重写完成后需要手动加回来git remote add origin 仓库地址这个设计一开始让我有点懵后来理解了它的用意——强制你确认重写结果之后再重新关联远程避免手滑直接推上去。3.4 只改最近一次提交的作者如果只是最后一次提交写错了那完全不用大动干戈一条命令搞定git commit --amend --author新名字 新邮箱example.com --no-edit--amend是修改最近一次提交--author指定新的作者信息--no-edit表示不改提交信息。这条命令会生成一个新的提交替换掉旧的哈希会变但因为没有推送到远程所以没有任何副作用。如果最近几次都写错了可以用交互式 rebasegit rebase -i HEAD~3把要改的那几次提交前面的pick改成edit然后逐个执行git commit --amend --author... --no-edit最后git rebase --continue。这种方式适合少量提交的精确修改比全量重写安全得多。4. 重置 Git 账号密码的几种真实场景4.1 认证失败到底是谁在报错先说一个容易混淆的点git push时弹出的认证失败报错来源可能是好几个地方。有的是远程服务拒绝了你过期的令牌有的是本地凭据管理器里存的旧密码不对还有的是 SSH 密钥不匹配。所以“重置密码”之前得先判断问题出在哪一层。常见的报错信息有这么几类。如果提示Authentication failed或者invalid username or password基本是凭据问题。如果提示Permission denied (publickey)那是 SSH 密钥的问题跟密码无关。如果提示403 Forbidden可能是权限不足或者令牌过期。看清楚报错再动手能少走很多弯路。判断当前用的是 HTTPS 还是 SSH可以看远程地址git remote -v地址以https://开头就是 HTTPS 方式以git开头就是 SSH 方式。两种方式的凭据管理完全不同下面分开讲。4.2 清理 HTTPS 方式缓存的凭据HTTPS 方式下Git 通常会把你的用户名和密码或令牌交给系统的凭据管理器缓存起来这样你不用每次推送都输入。但当你换了账号或者令牌过期时这个缓存就成了绊脚石。不同系统的凭据存储位置不一样。Windows 上一般用“凭据管理器”可以在控制面板里找到“Windows 凭据”里面会有git:https://...之类的条目删掉对应的即可。macOS 上用“钥匙串访问”搜索 git 相关的条目删除。Linux 上则取决于你配置的 credential helper可能是store明文存在~/.git-credentials、cache内存缓存或者libsecret。命令行清理方式先看当前用的 helpergit config --global credential.helper如果是store直接删文件rm ~/.git-credentials如果是cache清空缓存git credential-cache exit如果是manager或manager-coreWindows 常见可以用git credential-manager erase然后按提示输入协议和主机它会删掉对应条目。更简单的办法是直接在下一次推送时让它重新弹窗git config --global --unset credential.helper git push推送时会重新要求输入凭据输入新的之后再把 helper 设回去git config --global credential.helper manager提示现在很多代码托管平台已经不支持直接用账户密码推送了必须用个人访问令牌代替密码。如果你一直提示认证失败先确认自己用的是不是令牌而不是登录密码。这是新手最容易卡住的地方。4.3 SSH 方式的密钥重置SSH 方式不涉及“密码”而是密钥对。如果你换了机器或者密钥丢了需要重新生成一对然后把公钥传到远程账户里。生成新密钥ssh-keygen -t ed25519 -C 你的邮箱example.comed25519是目前推荐的算法比老的 RSA 更短更安全。一路回车即可也可以设置一个 passphrase 增加一层保护。生成后公钥在~/.ssh/id_ed25519.pub私钥在~/.ssh/id_ed25519私钥绝对不能外传。查看公钥内容cat ~/.ssh/id_ed25519.pub把输出整段复制到远程平台的 SSH 密钥设置里。然后测试连接ssh -T git主机名如果看到欢迎信息说明配置成功。如果提示权限被拒检查~/.ssh/config里有没有针对该主机的配置以及私钥权限是不是过宽Linux/macOS 上私钥权限必须是 600否则 SSH 会拒绝使用。chmod 600 ~/.ssh/id_ed25519这个权限问题我遇到过好几次尤其是从别处拷贝密钥文件过来的时候权限默认不对SSH 直接罢工报错还不太直观排查起来费劲。4.4 多账号共存时的凭据隔离如果你同时用两个账号比如一个工作一个个人HTTPS 方式下很容易出现凭据串号的问题——推工作仓库时用了个人凭据反之亦然。解决办法是给不同主机或不同路径配置不同的凭据。一种方式是在~/.ssh/config里为 SSH 配置不同的 Host 别名各自指定不同的密钥Host work-git HostName 工作主机 User git IdentityFile ~/.ssh/id_ed25519_work Host personal-git HostName 个人主机 User git IdentityFile ~/.ssh/id_ed25519_personal然后远程地址用别名git remote set-url origin gitwork-git:组名/仓库名.gitHTTPS 方式则可以用credential.useHttpPath让凭据按路径区分git config --global credential.useHttpPath true这样同一个主机下不同路径的仓库会用不同的凭据缓存避免互相覆盖。这个配置在多账号场景下几乎是必开的我强烈建议加上。5. 常见问题与排查速查5.1 改了配置但提交还是旧名字这是最高频的问题原因几乎都是仓库级配置覆盖了全局配置。排查方法前面提过用git config --show-origin --get user.name看生效来源。如果显示的是.git/config说明这个仓库单独设过需要在这个仓库里再改一次或者把仓库级的那条删掉git config --unset user.name git config --unset user.email删掉之后就会回落到全局配置。另一个可能的原因是你在 IDE 里提交而 IDE 有自己的 Git 配置入口改的地方和命令行不是同一处。这种情况要去 IDE 的设置里找版本控制相关的配置项。5.2 重写历史后推送被拒绝重写历史会改变提交哈希远程仓库的旧历史和你本地的新历史对不上普通push会被拒绝。这时候需要强制推送git push --force-with-lease我推荐用--force-with-lease而不是--force因为前者会在推送前检查远程有没有别人的新提交如果有就拒绝避免覆盖别人的工作。--force则是无脑覆盖危险得多。如果远程有分支保护规则不允许强制推送那就只能走合并请求的方式或者联系仓库管理员临时放开。这种情况在正规团队里很常见提前沟通比硬来强。5.3 凭据清了还是提示认证失败清完本地凭据还失败可能是这几个原因令牌本身过期了需要去平台重新生成账号被限制了推送权限或者网络层有代理干扰。逐一排查先用浏览器登录平台确认账号正常再重新生成一个令牌用新令牌试一次。如果还不行检查git config --global --get http.proxy有没有设代理有的话临时取消试试。还有一种隐蔽情况某些平台的令牌区分权限范围只读令牌是不能推送的。生成令牌时一定要勾选仓库写入权限这个细节很容易被忽略。5.4 速查表问题现象可能原因解决方向提交作者是旧名字仓库级配置覆盖全局用--show-origin定位并修改对应层历史提交作者错误配置改晚了用filter-branch或filter-repo重写推送提示认证失败凭据缓存过期清理 credential helper 缓存提示 publickey 被拒SSH 密钥问题重新生成密钥并上传公钥强制推送被拒分支保护规则走合并请求或联系管理员多账号凭据串号凭据未按路径隔离开启credential.useHttpPath6. 几个我踩过的坑和私房建议第一个坑是关于filter-branch的备份。它执行后会在refs/original/下留一份原始引用很多人以为这是自动备份就放心了结果清理的时候顺手删了等发现改错了想回滚已经找不回来了。我的做法是重写之前先整个仓库复制一份或者至少打个分支标签git branch backup-before-rewrite这样即使清理了refs/original/还有分支可以兜底。多占一点磁盘空间换的是心安。第二个坑是邮箱大小写。有些平台对邮箱大小写敏感NameExample.com和nameexample.com可能被当成两个不同的贡献者。重写历史时如果只匹配了一种写法另一种就漏掉了。稳妥的做法是用filter-repo的 mailmap它能处理多种映射而且不区分大小写的匹配可以自己写脚本控制。第三个建议是关于令牌管理。别把令牌硬编码在远程地址里比如https://用户名:令牌主机/仓库.git这种写法虽然方便但令牌会明文存在.git/config里一旦仓库目录被分享或者截图令牌就泄露了。正确做法是让凭据管理器去存远程地址保持干净的https://主机/仓库.git。第四个经验是关于团队协作。任何重写历史的操作在共享仓库上都必须提前通知所有人。我见过一次因为有人偷偷 force push 重写历史导致另外几个人的本地分支全部错乱花了大半天才恢复。重写历史不是技术难题是协作问题沟通到位比命令写对更重要。最后分享一个检查提交作者的小技巧。想快速看一个仓库里都有哪些作者可以用git shortlog -sne它会按提交数排序列出所有作者和邮箱一眼就能看出有没有混入奇怪的身份。接手新仓库或者准备开源之前跑一下能提前发现不少问题。这个命令我几乎每次整理仓库都会用比一个个翻 log 高效多了。