1. 先别急着删仓库pre-receive hook declined 到底卡在哪一步git push敲下去终端刷出一行红字! [remote rejected] master - master (pre-receive hook declined) error: failed to push some refs to gitexample.com:team/demo.git这个报错的意思是你的提交已经成功传到了远端服务器但在真正写入仓库之前被服务端的pre-receive钩子拦下来了。注意关键词是「服务端」——问题不在你的本地 Git也不在你的网络而是远端仓库的规则不允许这次推送落地。pre-receive是 Git 服务端在接收推送时执行的第一个钩子。它会在任何 ref 被更新之前运行只要它返回非零退出码整批推送就会被整体拒绝于是你看到remote rejected。常见的触发原因有四类分支保护规则、账号权限不足、提交信息不符合规范、以及钩子里自定义的检查逻辑比如禁止大文件、禁止直接推 master。很多人第一反应是git push -f强推这基本没用因为钩子是在服务端跑的强推同样会被拦。还有人怀疑是 SSH key 配错了其实如果 key 有问题报错会是Permission denied (publickey)跟这个完全不是一回事。这篇面向的是这样的场景团队在远端建了个空仓库给你开了 developer 权限你本地改完代码准备推 master结果被pre-receive hook declined挡住。我会按「远端钩子规则 → 分支保护 → 权限 → 提交规范」的顺序带你排查每一步都给可复制的命令和日志查看方式。顺带说一句多工具、多仓库环境下凭据管理很容易乱后面会讲怎么用 TaoToken 的统一 Key 通道把 API 凭据收拢到一处减少「到底哪个 key 生效了」这类干扰。先明确一点这个报错 90% 以上跟你的代码质量无关而是仓库策略问题。所以排查方向应该从「服务端允许什么」入手而不是反复折腾本地。2. 排查第一步读懂远端钩子日志与分支保护规则2.1 先确认你推的到底是哪个分支很多人以为自己推的是 master其实本地默认分支可能叫 main或者你当前在别的分支上。先看清楚git branch -vv git remote -v git statusgit branch -vv会显示本地分支和它跟踪的远端分支。如果输出里 master 后面没有[origin/master]说明跟踪关系没建立你推的时候可能推错了目标。2.2 用 verbose 模式拿到更详细的拒绝信息普通git push给的信息很有限加上--verbose能看到服务端返回的完整提示GIT_SSH_COMMANDssh -v git push origin master --verbose有些 Git 服务比如 GitLab、Gitee会在钩子拒绝时附带一行说明比如You are not allowed to push code to protected branches on this project。这行字就是最直接的线索。如果只看到pre-receive hook declined而没有附加说明说明钩子是自定义脚本需要找管理员看日志。2.3 分支保护是最常见的原因远端仓库通常会把 master 设为 protected branch受保护分支。受保护分支的典型规则是不允许直接 push只能通过 Merge Request / Pull Request 合并或者只有 Maintainer 及以上角色才能推。判断方法登录远端仓库的 Web 界面进入项目的 Settings设置找到 Repository 或「保护分支」相关配置。以 GitLab 为例路径是Settings → Repository → Protected branchesGitee 在管理 → 分支设置。如果你在这个页面看不到任何配置项或者点进去提示无权限那基本可以确认你的角色不够看不到也改不了保护规则。这里有个容易踩的坑developer 角色在多数平台上是不能创建新分支的取决于平台配置所以「新建一个分支推上去」这条退路未必走得通。excerpt 里提到的三种方法——关闭保护、新建分支、提权——本质上都需要管理员介入这一点要有心理预期。2.4 查看钩子到底检查了什么如果你有服务器访问权限自建 GitLab / Gitea可以直接看钩子脚本# GitLab 自定义钩子目录 ls -l /var/opt/gitlab/git-data/repositories/group/project.git/custom_hooks/ cat /var/opt/gitlab/git-data/repositories/group/project.git/custom_hooks/pre-receive如果是托管平台你看不到脚本但可以在推送时观察服务端返回。很多平台的钩子会检查提交信息格式比如必须带 issue 号、文件大小、是否包含敏感信息。这些规则一旦不满足同样报pre-receive hook declined。排查顺序建议固定下来先看分支保护再看权限最后看提交规范。因为前两者是「你根本没资格推」后者是「你有资格但内容不合规」处理方式完全不同。3. 可复制配置用 TaoToken 统一 Key 通道管理多工具凭据排查 Git 问题的过程中经常要同时开好几个工具终端里跑 git编辑器里用 AI 补全CI 里调模型接口。每个工具各配一套 API Key时间一长就分不清哪个 key 对应哪个服务出问题时排查成本很高。我习惯把模型类凭据统一走 TaoToken 的通道Base URL 和 Key 集中管理工具侧只引用同一份配置。TaoToken 的 API 入口是https://taotoken.net/api官网是https://taotoken.net/。下面给几份可直接复制的配置片段路径和字段名保持原样你按自己工具的实际位置放。3.1 通用 JSON 配置适用于多数支持 OpenAI 兼容协议的工具{ base_url: https://taotoken.net/api, api_key: sk-你的TaoTokenKey, model: claude-sonnet-4-20250514, timeout: 60 }把api_key换成你在控制台生成的 Key。注意 Base URL 结尾不要多加/v1具体以工具文档为准如果工具要求带版本路径就写成https://taotoken.net/api/v1。3.2 Claude Code 的 settings 配置Claude Code 读取的是 settings 文件把模型通道指向统一入口{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoTokenKey, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }这份配置放在 Claude Code 的 settings 路径下不同系统位置不同以官方文档为准。三件套要写全Base URL、Key、Model ID缺一个都可能连不上。3.3 Codex 的 auth.json如果你用 Codex 类工具认证信息写在auth.json里{ base_url: https://taotoken.net/api, api_key: sk-你的TaoTokenKey, model: gpt-4o }同样Base URL、Key、Model ID 三件套齐全。改完保存重启工具让配置生效。3.4 Cline / MCP 场景Cline 这类编辑器插件在设置里填 API Provider 时选 OpenAI Compatible然后{ provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: sk-你的TaoTokenKey, modelId: claude-sonnet-4-20250514 }MCP 服务如果要用到模型能力也是同样的三件套。这里提醒一句不要把 MCP 直连到生产数据库或生产环境凭据统一走通道管理权限按最小化原则给。3.5 为什么这对 Git 排查有帮助听起来模型配置和 git push 没关系但实际排查时你往往需要一边查文档、一边让 AI 帮你读报错、一边改配置。如果每个工具的 key 都散落各处很容易出现「改了 A 工具的 keyB 工具还在用旧的」这种混乱反而干扰对 Git 问题的判断。把凭据收拢到一处环境干净了排查思路也清晰。生成和管理 Key 的入口在控制台接入细节看接入文档。需要长期跑编码任务或 Agent 的可以了解下 Coding Plan按用量规划比零散调用更省心。4. 验证请求一次完整的 push 动作确认问题是否解决配置改完、权限也确认过之后别急着大改代码先用一次最小化的 push 验证问题是否真的解决。4.1 准备一个干净的测试提交git checkout master git pull origin master echo test README.md git add README.md git commit -m chore: test push after permission fix提交信息尽量规范很多钩子会检查格式。如果团队要求带 issue 号就写成chore: test push (#123)。4.2 执行推送并观察返回git push origin master成功的话你会看到类似Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Writing objects: 100% (3/3), 312 bytes | 312.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0) To example.com:team/demo.git a1b2c3d..d4e5f6a master - master最后一行master - master没有rejected字样就说明推送成功落地了。4.3 如果还是被拒用这个命令定位git push origin master --verbose 21 | tee push.log把输出存到push.log重点看remote:开头的行那是服务端返回的原始信息。如果还是只有pre-receive hook declined说明钩子没给友好提示需要管理员查服务端日志。4.4 验证远端确实收到了git ls-remote origin master这条命令会返回远端 master 的 commit hash。对比你本地git rev-parse master的结果如果一致说明推送真的成功了不是本地缓存骗你。4.5 用模型通道辅助读日志如果报错信息很长可以把push.log里的关键片段贴给模型对话让它帮你翻译成人话。前提是模型通道已经按第 3 节配好Base URL 和 Key 都指向统一入口。这样你不用在多个工具间来回切换排查效率会高不少。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth排查过程中会遇到各种报错这里按真实场景对照一遍。5.1 401 Unauthorized如果你在配置模型通道时看到 401说明 Key 无效或没带上。检查三件套Base URL 是否写成https://taotoken.net/apiKey 是否复制完整别漏了sk-前缀Model ID 是否是通道支持的型号。401 跟 Git 的Permission denied是两码事别混。5.2 local proxy failed这个报错通常出现在工具尝试走本地代理但代理没起来的时候。检查你的工具配置里有没有残留的 proxy 设置把它清掉让请求直连 Base URL。注意这里说的是工具自身的代理配置项不是让你去搞什么网络工具纯粹是配置文件里的字段要清理干净。5.3 reading choices 相关报错有些工具在解析模型返回时会报reading choices或类似字段缺失的错误。这多半是返回格式和工具预期不一致或者 Model ID 填错了导致返回了非预期结构。确认 Model ID 拼写正确Base URL 没有多余路径。5.4 OAuth 相关报错如果工具走 OAuth 流程报错检查回调地址和客户端配置。OAuth 和 API Key 是两套认证方式别在同一个工具里混用。用 Key 通道的话就把 OAuth 相关配置关掉或留空。5.5 Git 侧的高频错误对照报错含义处理方向pre-receive hook declined服务端钩子拒绝查分支保护/权限/提交规范Permission denied (publickey)SSH key 不对检查 key 是否加到远端账号failed to push some refs远端有新提交先git pull --rebaseprotected branch hook declined明确的分支保护找管理员开权限或走 MRremote: GitLab: You are not allowed角色不足提权到 Maintainer排查时按表格从上往下对基本能覆盖大部分情况。记住核心pre-receive hook declined是服务端策略问题本地怎么折腾都没用要么改规则要么换分支要么提权。6. 把凭据和权限都收拢push 才不会再莫名被拒回到最初那个场景developer 账号推 master 被拒本质是权限模型和分支保护在起作用。解决路径无非三条——管理员关闭保护、新建分支走 MR、或者给你提权。这三条都需要跟管理员沟通所以排查时先把证据准备好git push --verbose的输出、远端返回的原始信息、你尝试过的分支和命令。拿着这些去找管理员比空口说「推不上去」高效得多。另一个容易被忽视的点是凭据管理。Git 的 SSH key、模型通道的 API Key、CI 里的各种 token如果散落在不同地方出问题时你很难快速判断是权限问题还是凭据问题。把模型类凭据统一走 TaoToken 的通道Base URL 固定为https://taotoken.net/apiKey 在控制台集中生成和轮换工具侧只引用同一份配置。这样当pre-receive hook declined出现时你能确定它跟模型凭据无关排查范围直接缩小一半。最后给个实用习惯每次 push 被拒先跑git push origin branch --verbose 21 | tee push.log把日志留下来。不管是自己分析还是找管理员这份日志都是最硬的证据。分支保护规则改完后用第 4 节的最小化提交验证一次确认master - master干净落地再继续正常开发。
git push 报错 pre-receive hook declined 怎么破？TaoToken 统一 Key 通道下的排查清单
1. 先别急着删仓库pre-receive hook declined 到底卡在哪一步git push敲下去终端刷出一行红字! [remote rejected] master - master (pre-receive hook declined) error: failed to push some refs to gitexample.com:team/demo.git这个报错的意思是你的提交已经成功传到了远端服务器但在真正写入仓库之前被服务端的pre-receive钩子拦下来了。注意关键词是「服务端」——问题不在你的本地 Git也不在你的网络而是远端仓库的规则不允许这次推送落地。pre-receive是 Git 服务端在接收推送时执行的第一个钩子。它会在任何 ref 被更新之前运行只要它返回非零退出码整批推送就会被整体拒绝于是你看到remote rejected。常见的触发原因有四类分支保护规则、账号权限不足、提交信息不符合规范、以及钩子里自定义的检查逻辑比如禁止大文件、禁止直接推 master。很多人第一反应是git push -f强推这基本没用因为钩子是在服务端跑的强推同样会被拦。还有人怀疑是 SSH key 配错了其实如果 key 有问题报错会是Permission denied (publickey)跟这个完全不是一回事。这篇面向的是这样的场景团队在远端建了个空仓库给你开了 developer 权限你本地改完代码准备推 master结果被pre-receive hook declined挡住。我会按「远端钩子规则 → 分支保护 → 权限 → 提交规范」的顺序带你排查每一步都给可复制的命令和日志查看方式。顺带说一句多工具、多仓库环境下凭据管理很容易乱后面会讲怎么用 TaoToken 的统一 Key 通道把 API 凭据收拢到一处减少「到底哪个 key 生效了」这类干扰。先明确一点这个报错 90% 以上跟你的代码质量无关而是仓库策略问题。所以排查方向应该从「服务端允许什么」入手而不是反复折腾本地。2. 排查第一步读懂远端钩子日志与分支保护规则2.1 先确认你推的到底是哪个分支很多人以为自己推的是 master其实本地默认分支可能叫 main或者你当前在别的分支上。先看清楚git branch -vv git remote -v git statusgit branch -vv会显示本地分支和它跟踪的远端分支。如果输出里 master 后面没有[origin/master]说明跟踪关系没建立你推的时候可能推错了目标。2.2 用 verbose 模式拿到更详细的拒绝信息普通git push给的信息很有限加上--verbose能看到服务端返回的完整提示GIT_SSH_COMMANDssh -v git push origin master --verbose有些 Git 服务比如 GitLab、Gitee会在钩子拒绝时附带一行说明比如You are not allowed to push code to protected branches on this project。这行字就是最直接的线索。如果只看到pre-receive hook declined而没有附加说明说明钩子是自定义脚本需要找管理员看日志。2.3 分支保护是最常见的原因远端仓库通常会把 master 设为 protected branch受保护分支。受保护分支的典型规则是不允许直接 push只能通过 Merge Request / Pull Request 合并或者只有 Maintainer 及以上角色才能推。判断方法登录远端仓库的 Web 界面进入项目的 Settings设置找到 Repository 或「保护分支」相关配置。以 GitLab 为例路径是Settings → Repository → Protected branchesGitee 在管理 → 分支设置。如果你在这个页面看不到任何配置项或者点进去提示无权限那基本可以确认你的角色不够看不到也改不了保护规则。这里有个容易踩的坑developer 角色在多数平台上是不能创建新分支的取决于平台配置所以「新建一个分支推上去」这条退路未必走得通。excerpt 里提到的三种方法——关闭保护、新建分支、提权——本质上都需要管理员介入这一点要有心理预期。2.4 查看钩子到底检查了什么如果你有服务器访问权限自建 GitLab / Gitea可以直接看钩子脚本# GitLab 自定义钩子目录 ls -l /var/opt/gitlab/git-data/repositories/group/project.git/custom_hooks/ cat /var/opt/gitlab/git-data/repositories/group/project.git/custom_hooks/pre-receive如果是托管平台你看不到脚本但可以在推送时观察服务端返回。很多平台的钩子会检查提交信息格式比如必须带 issue 号、文件大小、是否包含敏感信息。这些规则一旦不满足同样报pre-receive hook declined。排查顺序建议固定下来先看分支保护再看权限最后看提交规范。因为前两者是「你根本没资格推」后者是「你有资格但内容不合规」处理方式完全不同。3. 可复制配置用 TaoToken 统一 Key 通道管理多工具凭据排查 Git 问题的过程中经常要同时开好几个工具终端里跑 git编辑器里用 AI 补全CI 里调模型接口。每个工具各配一套 API Key时间一长就分不清哪个 key 对应哪个服务出问题时排查成本很高。我习惯把模型类凭据统一走 TaoToken 的通道Base URL 和 Key 集中管理工具侧只引用同一份配置。TaoToken 的 API 入口是https://taotoken.net/api官网是https://taotoken.net/。下面给几份可直接复制的配置片段路径和字段名保持原样你按自己工具的实际位置放。3.1 通用 JSON 配置适用于多数支持 OpenAI 兼容协议的工具{ base_url: https://taotoken.net/api, api_key: sk-你的TaoTokenKey, model: claude-sonnet-4-20250514, timeout: 60 }把api_key换成你在控制台生成的 Key。注意 Base URL 结尾不要多加/v1具体以工具文档为准如果工具要求带版本路径就写成https://taotoken.net/api/v1。3.2 Claude Code 的 settings 配置Claude Code 读取的是 settings 文件把模型通道指向统一入口{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoTokenKey, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }这份配置放在 Claude Code 的 settings 路径下不同系统位置不同以官方文档为准。三件套要写全Base URL、Key、Model ID缺一个都可能连不上。3.3 Codex 的 auth.json如果你用 Codex 类工具认证信息写在auth.json里{ base_url: https://taotoken.net/api, api_key: sk-你的TaoTokenKey, model: gpt-4o }同样Base URL、Key、Model ID 三件套齐全。改完保存重启工具让配置生效。3.4 Cline / MCP 场景Cline 这类编辑器插件在设置里填 API Provider 时选 OpenAI Compatible然后{ provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: sk-你的TaoTokenKey, modelId: claude-sonnet-4-20250514 }MCP 服务如果要用到模型能力也是同样的三件套。这里提醒一句不要把 MCP 直连到生产数据库或生产环境凭据统一走通道管理权限按最小化原则给。3.5 为什么这对 Git 排查有帮助听起来模型配置和 git push 没关系但实际排查时你往往需要一边查文档、一边让 AI 帮你读报错、一边改配置。如果每个工具的 key 都散落各处很容易出现「改了 A 工具的 keyB 工具还在用旧的」这种混乱反而干扰对 Git 问题的判断。把凭据收拢到一处环境干净了排查思路也清晰。生成和管理 Key 的入口在控制台接入细节看接入文档。需要长期跑编码任务或 Agent 的可以了解下 Coding Plan按用量规划比零散调用更省心。4. 验证请求一次完整的 push 动作确认问题是否解决配置改完、权限也确认过之后别急着大改代码先用一次最小化的 push 验证问题是否真的解决。4.1 准备一个干净的测试提交git checkout master git pull origin master echo test README.md git add README.md git commit -m chore: test push after permission fix提交信息尽量规范很多钩子会检查格式。如果团队要求带 issue 号就写成chore: test push (#123)。4.2 执行推送并观察返回git push origin master成功的话你会看到类似Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Writing objects: 100% (3/3), 312 bytes | 312.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0) To example.com:team/demo.git a1b2c3d..d4e5f6a master - master最后一行master - master没有rejected字样就说明推送成功落地了。4.3 如果还是被拒用这个命令定位git push origin master --verbose 21 | tee push.log把输出存到push.log重点看remote:开头的行那是服务端返回的原始信息。如果还是只有pre-receive hook declined说明钩子没给友好提示需要管理员查服务端日志。4.4 验证远端确实收到了git ls-remote origin master这条命令会返回远端 master 的 commit hash。对比你本地git rev-parse master的结果如果一致说明推送真的成功了不是本地缓存骗你。4.5 用模型通道辅助读日志如果报错信息很长可以把push.log里的关键片段贴给模型对话让它帮你翻译成人话。前提是模型通道已经按第 3 节配好Base URL 和 Key 都指向统一入口。这样你不用在多个工具间来回切换排查效率会高不少。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth排查过程中会遇到各种报错这里按真实场景对照一遍。5.1 401 Unauthorized如果你在配置模型通道时看到 401说明 Key 无效或没带上。检查三件套Base URL 是否写成https://taotoken.net/apiKey 是否复制完整别漏了sk-前缀Model ID 是否是通道支持的型号。401 跟 Git 的Permission denied是两码事别混。5.2 local proxy failed这个报错通常出现在工具尝试走本地代理但代理没起来的时候。检查你的工具配置里有没有残留的 proxy 设置把它清掉让请求直连 Base URL。注意这里说的是工具自身的代理配置项不是让你去搞什么网络工具纯粹是配置文件里的字段要清理干净。5.3 reading choices 相关报错有些工具在解析模型返回时会报reading choices或类似字段缺失的错误。这多半是返回格式和工具预期不一致或者 Model ID 填错了导致返回了非预期结构。确认 Model ID 拼写正确Base URL 没有多余路径。5.4 OAuth 相关报错如果工具走 OAuth 流程报错检查回调地址和客户端配置。OAuth 和 API Key 是两套认证方式别在同一个工具里混用。用 Key 通道的话就把 OAuth 相关配置关掉或留空。5.5 Git 侧的高频错误对照报错含义处理方向pre-receive hook declined服务端钩子拒绝查分支保护/权限/提交规范Permission denied (publickey)SSH key 不对检查 key 是否加到远端账号failed to push some refs远端有新提交先git pull --rebaseprotected branch hook declined明确的分支保护找管理员开权限或走 MRremote: GitLab: You are not allowed角色不足提权到 Maintainer排查时按表格从上往下对基本能覆盖大部分情况。记住核心pre-receive hook declined是服务端策略问题本地怎么折腾都没用要么改规则要么换分支要么提权。6. 把凭据和权限都收拢push 才不会再莫名被拒回到最初那个场景developer 账号推 master 被拒本质是权限模型和分支保护在起作用。解决路径无非三条——管理员关闭保护、新建分支走 MR、或者给你提权。这三条都需要跟管理员沟通所以排查时先把证据准备好git push --verbose的输出、远端返回的原始信息、你尝试过的分支和命令。拿着这些去找管理员比空口说「推不上去」高效得多。另一个容易被忽视的点是凭据管理。Git 的 SSH key、模型通道的 API Key、CI 里的各种 token如果散落在不同地方出问题时你很难快速判断是权限问题还是凭据问题。把模型类凭据统一走 TaoToken 的通道Base URL 固定为https://taotoken.net/apiKey 在控制台集中生成和轮换工具侧只引用同一份配置。这样当pre-receive hook declined出现时你能确定它跟模型凭据无关排查范围直接缩小一半。最后给个实用习惯每次 push 被拒先跑git push origin branch --verbose 21 | tee push.log把日志留下来。不管是自己分析还是找管理员这份日志都是最硬的证据。分支保护规则改完后用第 4 节的最小化提交验证一次确认master - master干净落地再继续正常开发。
