1. 先搞清楚 remote rejected 到底在拦什么你敲下git push终端刷完Resolving deltas: 100%紧接着蹦出一行红字! [remote rejected] main - main (push declined due to repository rule violations)。这不是网络问题也不是权限不够而是 GitHub 的推送保护Push Protection在服务端把你的提交拦下来了。它扫描到你这次要推上去的 commit 里含有疑似密钥的字符串于是直接拒绝整个 ref 的更新。这个机制属于 GitHub 仓库规则Repository rules的一部分常见报错前缀是remote: error: GH013: Repository rule violations found for refs/heads/main。下面还会列出具体命中的规则比如Push cannot contain secrets并给出命中位置哪个 commit、哪个文件、第几行。很多人第一次遇到会以为是 SSH key 配错了反复重配 remote其实方向完全跑偏。它适合谁看适合所有把代码往 GitHub 推、并且项目里可能混入过 API Key、SecretId、Token 的开发者。尤其是前端项目里打包产物、第三方库的 min.js、.env被误提交的情况命中率极高。我见过最典型的一次是libs/twikoo/twikoo.all.min.js这种压缩文件里带了一段云厂商的 Secret ID自己完全没印象但扫描器认得。要恢复推送核心就两条路要么把密钥从提交历史里彻底移除要么在确认该密钥无害后走 GitHub 提供的放行链接。但更值得做的是从源头治理——用统一的 Key 管理方式让本地和 CI 都不再往仓库里塞明文密钥。这也是后面要讲的 TaoToken 统一 Key 接入的切入点。2. 用 TaoToken 统一 Key 管住 secrets 源头密钥为什么会进仓库绝大多数不是故意的而是「本地调试图省事直接写死在代码或配置文件里提交时忘了删」。要根治思路是把密钥从代码里挪出去统一放到环境变量本地和 CI 用同一套 Key 来源。TaoToken 在这里的角色是提供一个统一的 API Key 入口让你在本地开发、CI 流水线里都通过环境变量引用同一个 Key而不是把 Key 硬编码进任何会被 git 跟踪的文件。它的控制台可以创建和管理 API Keys配合 Coding Plan 还能覆盖长期编码和 Agent 场景的调用需求。具体来说你需要做三件事第一在 TaoToken 控制台创建一个 API Key这个 Key 只存在于你的密码管理器和 CI 的加密变量里永远不进 git。第二本地用.env或 shell 环境变量引用它并且把.env加进.gitignore。第三CI 里通过仓库的 Secrets 功能注入工作流里用${{ secrets.XXX }}读取。这样即使你某次手滑git add .被跟踪的文件里也只有变量名没有真实 Key 值GitHub 的 secret scanning 就不会命中。下面给出可直接复制的配置骨架。先看.gitignore里必须有的几行# 环境变量文件绝不提交 .env .env.local .env.*.local # 常见密钥载体 *.pem *.key secrets.json credentials.json # 打包产物里可能内嵌密钥按需忽略 dist/ build/然后是本地开发用的.env.example这个文件可以提交用来告诉协作者需要哪些变量但值留空# .env.example —— 可提交仅作变量名说明 TAOTOKEN_API_KEY TAOTOKEN_BASE_URLhttps://taotoken.net/api真正的.env不提交内容长这样# .env —— 已在 .gitignore 中绝不提交 TAOTOKEN_API_KEYsk-你的真实key TAOTOKEN_BASE_URLhttps://taotoken.net/api在代码里读取时用环境变量而不是字面量。以 Node 为例// config.js —— 只读环境变量不写死任何 Key const apiKey process.env.TAOTOKEN_API_KEY; const baseUrl process.env.TAOTOKEN_BASE_URL || https://taotoken.net/api; if (!apiKey) { throw new Error(缺少 TAOTOKEN_API_KEY请检查 .env 或 CI 环境变量); } module.exports { apiKey, baseUrl };这样一套下来你的仓库里永远不会出现真实 Key。GitHub 扫描器扫的是提交内容提交里没有 Key自然不会触发push declined due to repository rule violations。3. 可复制的 .git/config 与 pre-commit 配置骨架光靠自觉不够得让工具在提交前帮你拦一道。pre-commit 钩子是最轻量的方案能在git commit阶段就发现疑似密钥避免它进入历史后再去处理——要知道一旦进了历史清理起来要用filter-repo或filter-branch麻烦得多。先看.git/config里值得确认的几项。很多人 remote 配错协议导致排查时混淆视听[core] repositoryformatversion 0 filemode true bare false logallrefupdates true [remote origin] url gitgithub.com:你的用户名/你的仓库.git fetch refs/heads/*:refs/remotes/origin/* [branch main] remote origin merge refs/heads/main [user] name 你的名字 email 你的邮箱确认remote.origin.url指向正确仓库branch.main.merge指向refs/heads/main。如果这里写错push 的目标 ref 就不对报错信息也会变得难以理解。接下来是 pre-commit 配置。在仓库根目录建.pre-commit-config.yaml# .pre-commit-config.yaml repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.18.0 hooks: - id: gitleaks name: 检测提交中的密钥 entry: gitleaks protect --staged --verbose language: system pass_filenames: false安装并启用钩子# 安装 pre-commitPython 环境 pip install pre-commit # 在仓库根目录安装钩子 pre-commit install # 手动跑一次全量检查确认配置生效 pre-commit run --all-files如果你不想引入 Python 依赖也可以用纯 shell 写一个轻量钩子放在.git/hooks/pre-commit#!/bin/sh # .git/hooks/pre-commit —— 轻量密钥扫描 # 注意此文件在 .git 目录内不会被提交需手动分发或脚本生成 PATTERNSsk-[A-Za-z0-9]{20,}|AKID[A-Za-z0-9]{13,}|SecretId|SecretKey|BEGIN RSA PRIVATE KEY STAGED$(git diff --cached --name-only --diff-filterACM) if [ -z $STAGED ]; then exit 0 fi HIT0 for f in $STAGED; do if grep -nE $PATTERNS $f /dev/null 21; then echo 疑似密钥命中$f grep -nE $PATTERNS $f HIT1 fi done if [ $HIT -eq 1 ]; then echo 提交被拦截请移除上述密钥改用环境变量。 exit 1 fi exit 0给它执行权限chmod x .git/hooks/pre-commit这套钩子的价值在于它在你git commit的那一刻就报错而不是等你git push到 GitHub 才被服务端拒绝。本地拦截的成本远低于事后清理历史。4. CI 环境变量接入与 git push 复现验证本地管住了CI 也不能漏。GitHub Actions 里密钥通过仓库的 Settings → Secrets and variables → Actions 注入工作流里用secrets上下文读取。下面是一个完整的 workflow 骨架展示 TaoToken 统一 Key 在 CI 中的接入方式# .github/workflows/ci.yml name: CI on: push: branches: [main] pull_request: branches: [main] jobs: build: runs-on: ubuntu-latest steps: - name: 检出代码 uses: actions/checkoutv4 - name: 设置 Node uses: actions/setup-nodev4 with: node-version: 20 - name: 安装依赖 run: npm ci - name: 运行测试注入 TaoToken Key env: TAOTOKEN_API_KEY: ${{ secrets.TAOTOKEN_API_KEY }} TAOTOKEN_BASE_URL: https://taotoken.net/api run: npm test - name: 构建 run: npm run build关键点TAOTOKEN_API_KEY的值来自secrets.TAOTOKEN_API_KEY这个值在仓库设置里配置不会出现在 workflow 文件里也不会被 git 跟踪。你在 TaoToken 控制台创建的 Key填进 GitHub 的 Secret 即可本地和 CI 共用同一个 Key 来源管理成本最低。现在来复现并验证整个流程。假设你之前已经踩过remote rejected按下面步骤走一遍# 1. 确认当前分支和远程 git branch -vv git remote -v # 2. 检查暂存区里有没有疑似密钥 git diff --cached | grep -iE sk-|secret|token|password || echo 暂存区未发现明显密钥 # 3. 如果发现密钥从暂存区移除并改用环境变量 git restore --staged path/to/leaked-file # 4. 确认 .env 已被忽略 git check-ignore -v .env # 5. 正常提交 git add . git commit -m refactor: 密钥改用环境变量注入 # 6. 推送 git push origin main如果推送成功终端会显示类似Enumerating objects: 12, done. Counting objects: 100% (12/12), done. Delta compression using up to 8 threads Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 1.2 KiB | 1.2 MiB/s, done. Total 7 (delta 3), reused 0 (delta 0), pack-reused 0 To github.com:你的用户名/你的仓库.git a1b2c3d..e4f5g6h main - main看到main - main且没有remote rejected就说明规则冲突已解除。如果仍然被拒说明历史提交里还有密钥需要继续往下排查。5. 本篇常见错排查报错一GH013: Repository rule violations found for refs/heads/main但当前提交里明明没有密钥。原因通常是历史 commit 里含有密钥GitHub 扫描的是整个待推送的 commit 范围不只是最新一次提交。用下面的命令定位# 查看将要推送的提交范围 git log origin/main..main --oneline # 在范围内搜索疑似密钥 git log origin/main..main -p | grep -iE sk-|secretid|secretkey|password找到命中 commit 后用git rebase -i或git filter-repo清理。简单场景下如果只是最近一次提交可以# 修改最近一次提交移除密钥文件 git rm --cached path/to/leaked-file echo path/to/leaked-file .gitignore git commit --amend --no-edit git push origin main报错二放行链接点了同意重新 push 还是被拒。放行unblock只对当前这一个 secret 生效如果同一个 commit 里有多个不同的 secret或者你 amend 后 commit hash 变了之前的放行就失效了。正确做法是逐个处理或者干脆把密钥从提交里移除一劳永逸。放行链接适合「确认这个密钥是测试用的、无害的」场景生产密钥不要走放行。报错三pre-commit钩子没生效提交时没拦截。检查钩子是否真的安装ls -la .git/hooks/pre-commit pre-commit run --all-files如果.git/hooks/pre-commit不存在说明pre-commit install没跑成功。另外注意git commit --no-verify会跳过钩子排查时确认自己没加这个参数。报错四CI 里读不到TAOTOKEN_API_KEY报 undefined。先确认 GitHub 仓库的 Secret 名称拼写完全一致大小写敏感。然后在 workflow 里确认env块写在了正确的 step 上。可以在 CI 里加一行调试注意不要打印真实值- name: 确认变量存在 env: TAOTOKEN_API_KEY: ${{ secrets.TAOTOKEN_API_KEY }} run: | if [ -z $TAOTOKEN_API_KEY ]; then echo 变量为空请检查仓库 Secret 配置 exit 1 fi echo 变量已注入长度${#TAOTOKEN_API_KEY}报错五.env明明在.gitignore里还是被跟踪了。.gitignore只对未跟踪文件生效。如果.env之前已经被git add过需要先取消跟踪git rm --cached .env git commit -m chore: 停止跟踪 .env之后.gitignore才会对它生效。6. 把 Key 管理和推送规则一起理顺回到最初那个报错push declined due to repository rule violations本质上是 GitHub 在替你做最后一道防线。它拦住的可能是你无意中泄露的生产密钥也可能是第三方库里的历史遗留。与其每次被拦了再去点放行链接不如把密钥从代码里彻底挪出去。我自己的做法是本地.env pre-commit 钩子拦截 CI 用仓库 Secret 注入三层下来基本不会再触发 secrets 相关的 push 拒绝。TaoToken 的统一 Key 在这里承担的是「一个 Key 走通本地和 CI」的角色你可以在控制台创建和管理它配合 Coding Plan 覆盖长期编码场景。如果你现在正卡在某个具体的报错上建议先去 TaoToken 控制台把 API Keys 建好再对照接入文档把环境变量接进项目需要验证模型调用是否正常可以直接用模型对话快速试一次如果是长期编码或 Agent 场景Coding Plan 会更合适。把 Key 管住push 这条路自然就顺了。
