1. 从本地到 Release为什么“上传 GitHub”远不止三条命令很多人第一次把项目传到 GitHub脑子里只有三条命令git add、git commit、git push。临时备份确实够用但只要目标从“存一下”变成“正式发一个版本”事情立刻变多项目里有没有混进.env、Token、私钥dist/、缓存、虚拟环境该不该进 Git本地origin到底指向哪个仓库远端已经有提交时本地历史能不能普通 fast-forward版本号从哪来Tag 是不是已经存在Release Notes、源码 ZIP、附加资产和 SHA-256 校验和怎么一起生成gh release create返回 0 之后怎么证明 GitHub 上的分支、Tag 和资产就是这次结果我这次要聊的就是把这条完整链路做成一个可复用的 Skillgithub-project-publisher。它面向需要频繁发版的独立开发者把“提交、打 Tag、归档、校验”四步收进一个入口内部再由模块化脚本完成审计、Git 操作、版本准备、Release 创建和独立验证。本文会给出 Skill 的config.toml骨架与settings.json配置片段并演示每一步可复制的命令与验证动作目标是一次配置后稳定复用。先说清楚它适合谁如果你只是偶尔备份代码原生 Git 就够了但如果你要对外发版、要给别人下载地址、要保证“下载到的 ZIP 就是这次提交”那这套流程能帮你把容易漏掉的检查固定下来。核心检索词就三个GitHub、Release、Skill——一个把本地 Git 项目推到 GitHub 并生成正式版本的自动化技能。2. 前置准备TaoToken 与运行环境怎么配在讲 Skill 之前先把模型调用这一层配好。我用的中转入口是 TaoToken官网地址https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基址是https://taotoken.net/api这个不加 UTM。它的作用是给 Skill 里的 AI 编排层提供稳定的模型对话能力比如让模型理解“把当前项目以 1.2.3 发布”这种自然语言意图再翻译成确定性的脚本参数。你需要先拿到 API Key。进入控制台创建密钥https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite然后在 API Keys 页面生成https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite。生成后不要写进代码仓库放到系统环境变量里比如TAOTOKEN_API_KEY。运行环境分两层分支发布只需要 Python 3.10 和系统 Git如果要创建 GitHub Release额外需要安装并登录 GitHub CLIgh。认证交给 Git Credential Manager、SSH Agent 或gh auth login自己管理Skill 不读取 Token也不要求你把 Token 粘贴到聊天里。Skill 的目录结构建议这样组织config.toml放在 Skill 根目录settings.json放在agents/下# config.toml —— Skill 骨架 [skill] name github-project-publisher version 1.0.0 entry scripts/publish_project.py verify scripts/verify_publish.py [model] provider taotoken base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY chat_path /v1/chat/completions [defaults] branch main dry_run true receipt_dir .receipts{ settings: { model: claude-sonnet, temperature: 0.2, max_tokens: 4096 }, permissions: { default_mode: dry-run, execute_flag: --execute, release_flag: --release, allow_force_push: false, allow_overwrite_tag: false }, safety: { block_secrets: true, max_file_mib: 100, require_confirm_repository: true } }这里有两个设计点值得强调。第一dry_run true是默认值任何写操作都要显式加--execute第二allow_force_push和allow_overwrite_tag直接写死为false从配置层面堵住“自动覆盖历史”这种危险动作。模型对话能力可以在这里验证https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite确认 Key 能正常返回再往下走。3. 可复制配置提交、Tag、归档、校验四步命令配置好之后四步链路就能跑起来了。我把它拆成“先预览、再执行、后验证”的节奏每一步都有对应命令。第一步dry-run 预览。这条命令不修改任何 Git 状态只输出计划python github-project-publisher/scripts/publish_project.py \ --project /path/to/project \ --remote https://github.com/OWNER/REPOSITORY \ --confirm-repository OWNER/REPOSITORY \ --branch main \ --commit-message feat: publish project \ --receipt .receipts/dry-run.jsonWindows PowerShell 用反引号换行参数完全一致。跑完先看 receipt 里的候选文件、远端、blocker、warning 和 operations 字段。第二步提交并推送分支。确认计划没问题后在同一条命令加--execute如果远端已有同历史提交再加--allow-existingpython github-project-publisher/scripts/publish_project.py \ --project /path/to/project \ --remote https://github.com/OWNER/REPOSITORY \ --confirm-repository OWNER/REPOSITORY \ --allow-existing \ --branch main \ --commit-message feat: publish project \ --execute \ --receipt .receipts/publish-receipt.json第三步创建版本 Release。先确认登录状态gh auth status然后同时带上--release和--executepython github-project-publisher/scripts/publish_project.py \ --project /path/to/project \ --remote https://github.com/OWNER/REPOSITORY \ --confirm-repository OWNER/REPOSITORY \ --allow-existing \ --version 1.2.3 \ --release \ --asset dist/project-windows.zip \ --execute \ --receipt .receipts/release-receipt.json版本号会统一规范成v1.2.3。如果本地或远端已存在同名 Tag流程直接停止不覆盖旧版本。源码包用最终提交执行git archive所以 ZIP 只包含 Git 里的正式内容不会把工作区缓存或未跟踪文件打进去。额外资产必须通过--asset显式指定Skill 会把源码 ZIP 和这些资产复制到项目外的产物目录并为每个上传文件生成SHA256SUMS.txt。第四步独立校验。这一步刻意和发布器分开用第二次查询验证结果python github-project-publisher/scripts/verify_publish.py \ --project /path/to/project \ --remote https://github.com/OWNER/REPOSITORY \ --branch main \ --json-out .receipts/independent-verification.json四步下来提交、Tag、归档、校验各自有明确的输入输出receipt 文件把候选文件、计划动作、最终提交和验证结果都留了痕。长期做编码和 Agent 编排的话可以考虑用 Coding Plan 把这类重复发布任务固定成常驻能力https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite。4. 验证请求与成功结果怎么证明“真的发布成功”验证分三层我按从轻到重排。第一层是标准库单元测试不依赖网络python -m unittest discover -s tests -v我实测下来是 24/24 通过其中 4 个测试专门覆盖这个 SkillGitHub 仓库 slug 与版本号规范化、Secret 和大文件阻断只报告规则与路径不泄露原值、Release Notes 与源码归档可复现、针对本地 bare remote 执行真实 commit 和普通 push 并验证远端 SHA。本地 bare remote 这点很关键它让执行路径不依赖临时公开仓库能测到真正的 Git 写入和 fetch而不是只 mock 子进程返回值。第二层是用真实仓库自发布。dry-run 的 receipt 里候选文件 58 个、候选总大小 287,679 B、blocker 0、warning 0最终分支main最终提交7a90e7e...分支校验true。对应提交包含 10 个变更文件新增 1,102 行、删除 3 行。第三层是脱离发布器再次验证也就是上面那条verify_publish.py命令输出类似{ localHead: 7a90e7eede0c5029c131d7496ee479ae8353f539, remoteBranch: 7a90e7eede0c5029c131d7496ee479ae8353f539, branchMatches: true, verified: true }branchMatches为true说明本地 HEAD 和远端分支精确一致。这里要诚实说明这次真实公开验证执行的是 branch-only 发布Release 功能已经实现并通过本地 Git 仓库闭环测试覆盖了版本、Notes、源码归档和校验和逻辑但我没有为了写文章额外创建一个没有实际版本意义的公开 Release。功能已实现和已在公开仓库创建 Release 是两回事不能混着说。5. 本篇常见错排查报错一remote branch is not ancestor of local HEAD。说明非空远端和本地不是同一段历史。默认会停止不会自动--allow-unrelated-histories也不会 force push。先确认是不是选错了目录或仓库确实要覆盖再人工处理。报错二secret detected in path:line。审计命中了.env、私钥或 Token 形态。报告只记录规则、路径和行号不复制匹配到的秘密值避免扫描报告本身变成泄露文件。把敏感文件加进.gitignore并git rm --cached后再跑。报错三file exceeds 100 MiB。GitHub 单文件硬限制是 100 MiB超过直接阻断。大文件更适合作为 Release 附件或走 Git LFS不要硬塞进普通提交。报错四tag v1.2.3 already exists。同名 Tag 已存在流程停止不覆盖。要么换版本号要么人工确认后删除旧 TagSkill 不会替你改写已有版本。报错五gh: command not found或gh auth status失败。创建 Release 依赖 GitHub CLI。装好gh后执行gh auth loginSkill 只使用系统现有登录状态不读取 Token。报错六confirm-repository mismatch。传入的--confirm-repository和实际远端 URL 不一致。这是防止推错仓库的关键检查核对OWNER/REPOSITORY拼写即可。接入和排障相关的文档可以对照看https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite。如果用的是 Claude Code 这类编码环境接入说明在https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentClaudeCodeAnthropicutm_campaignrewrite。6. 把发布链路固定成可复用能力回到最初的问题完全自动上传 GitHub最有价值的部分不是把十几条命令压成一条而是让这条命令仍然能回答——它准备上传什么为什么拒绝某个文件或远端获得了哪一层写权限有没有改写历史或远端配置Release 里每个文件来自哪个最终提交最后谁证明 GitHub 上的结果真的一致我采用的结构是一个综合 Skill 负责完整用户意图内部模块化脚本负责确定性执行dry-run 和显式参数负责权限边界独立验证器给出第二份证据。这样“全自动”不等于“遇到任何情况都继续向前”而是在边界清楚、证据充分、授权明确时把重复动作做完遇到历史冲突、秘密值或目标不一致时自动停止。如果你正在把本地工具、网页项目、Python 包或小游戏仓库整理成正式开源项目可以先按上面的config.toml和settings.json配好跑一次 dry-run。它给出的候选文件、远端历史和 Release 计划往往比直接执行一次 push 更能暴露真正的发布问题。模型对话和 API 接入从https://taotoken.net/api开始密钥在https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite管理配好之后这套四步链路就能稳定复用了。 用 TaoToken 把 GitHub 提交、Tag、Release 归档做成一个 Skill：从本地到版本发布一次跑通
1. 从本地到 Release为什么“上传 GitHub”远不止三条命令很多人第一次把项目传到 GitHub脑子里只有三条命令git add、git commit、git push。临时备份确实够用但只要目标从“存一下”变成“正式发一个版本”事情立刻变多项目里有没有混进.env、Token、私钥dist/、缓存、虚拟环境该不该进 Git本地origin到底指向哪个仓库远端已经有提交时本地历史能不能普通 fast-forward版本号从哪来Tag 是不是已经存在Release Notes、源码 ZIP、附加资产和 SHA-256 校验和怎么一起生成gh release create返回 0 之后怎么证明 GitHub 上的分支、Tag 和资产就是这次结果我这次要聊的就是把这条完整链路做成一个可复用的 Skillgithub-project-publisher。它面向需要频繁发版的独立开发者把“提交、打 Tag、归档、校验”四步收进一个入口内部再由模块化脚本完成审计、Git 操作、版本准备、Release 创建和独立验证。本文会给出 Skill 的config.toml骨架与settings.json配置片段并演示每一步可复制的命令与验证动作目标是一次配置后稳定复用。先说清楚它适合谁如果你只是偶尔备份代码原生 Git 就够了但如果你要对外发版、要给别人下载地址、要保证“下载到的 ZIP 就是这次提交”那这套流程能帮你把容易漏掉的检查固定下来。核心检索词就三个GitHub、Release、Skill——一个把本地 Git 项目推到 GitHub 并生成正式版本的自动化技能。2. 前置准备TaoToken 与运行环境怎么配在讲 Skill 之前先把模型调用这一层配好。我用的中转入口是 TaoToken官网地址https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基址是https://taotoken.net/api这个不加 UTM。它的作用是给 Skill 里的 AI 编排层提供稳定的模型对话能力比如让模型理解“把当前项目以 1.2.3 发布”这种自然语言意图再翻译成确定性的脚本参数。你需要先拿到 API Key。进入控制台创建密钥https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite然后在 API Keys 页面生成https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite。生成后不要写进代码仓库放到系统环境变量里比如TAOTOKEN_API_KEY。运行环境分两层分支发布只需要 Python 3.10 和系统 Git如果要创建 GitHub Release额外需要安装并登录 GitHub CLIgh。认证交给 Git Credential Manager、SSH Agent 或gh auth login自己管理Skill 不读取 Token也不要求你把 Token 粘贴到聊天里。Skill 的目录结构建议这样组织config.toml放在 Skill 根目录settings.json放在agents/下# config.toml —— Skill 骨架 [skill] name github-project-publisher version 1.0.0 entry scripts/publish_project.py verify scripts/verify_publish.py [model] provider taotoken base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY chat_path /v1/chat/completions [defaults] branch main dry_run true receipt_dir .receipts{ settings: { model: claude-sonnet, temperature: 0.2, max_tokens: 4096 }, permissions: { default_mode: dry-run, execute_flag: --execute, release_flag: --release, allow_force_push: false, allow_overwrite_tag: false }, safety: { block_secrets: true, max_file_mib: 100, require_confirm_repository: true } }这里有两个设计点值得强调。第一dry_run true是默认值任何写操作都要显式加--execute第二allow_force_push和allow_overwrite_tag直接写死为false从配置层面堵住“自动覆盖历史”这种危险动作。模型对话能力可以在这里验证https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite确认 Key 能正常返回再往下走。3. 可复制配置提交、Tag、归档、校验四步命令配置好之后四步链路就能跑起来了。我把它拆成“先预览、再执行、后验证”的节奏每一步都有对应命令。第一步dry-run 预览。这条命令不修改任何 Git 状态只输出计划python github-project-publisher/scripts/publish_project.py \ --project /path/to/project \ --remote https://github.com/OWNER/REPOSITORY \ --confirm-repository OWNER/REPOSITORY \ --branch main \ --commit-message feat: publish project \ --receipt .receipts/dry-run.jsonWindows PowerShell 用反引号换行参数完全一致。跑完先看 receipt 里的候选文件、远端、blocker、warning 和 operations 字段。第二步提交并推送分支。确认计划没问题后在同一条命令加--execute如果远端已有同历史提交再加--allow-existingpython github-project-publisher/scripts/publish_project.py \ --project /path/to/project \ --remote https://github.com/OWNER/REPOSITORY \ --confirm-repository OWNER/REPOSITORY \ --allow-existing \ --branch main \ --commit-message feat: publish project \ --execute \ --receipt .receipts/publish-receipt.json第三步创建版本 Release。先确认登录状态gh auth status然后同时带上--release和--executepython github-project-publisher/scripts/publish_project.py \ --project /path/to/project \ --remote https://github.com/OWNER/REPOSITORY \ --confirm-repository OWNER/REPOSITORY \ --allow-existing \ --version 1.2.3 \ --release \ --asset dist/project-windows.zip \ --execute \ --receipt .receipts/release-receipt.json版本号会统一规范成v1.2.3。如果本地或远端已存在同名 Tag流程直接停止不覆盖旧版本。源码包用最终提交执行git archive所以 ZIP 只包含 Git 里的正式内容不会把工作区缓存或未跟踪文件打进去。额外资产必须通过--asset显式指定Skill 会把源码 ZIP 和这些资产复制到项目外的产物目录并为每个上传文件生成SHA256SUMS.txt。第四步独立校验。这一步刻意和发布器分开用第二次查询验证结果python github-project-publisher/scripts/verify_publish.py \ --project /path/to/project \ --remote https://github.com/OWNER/REPOSITORY \ --branch main \ --json-out .receipts/independent-verification.json四步下来提交、Tag、归档、校验各自有明确的输入输出receipt 文件把候选文件、计划动作、最终提交和验证结果都留了痕。长期做编码和 Agent 编排的话可以考虑用 Coding Plan 把这类重复发布任务固定成常驻能力https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite。4. 验证请求与成功结果怎么证明“真的发布成功”验证分三层我按从轻到重排。第一层是标准库单元测试不依赖网络python -m unittest discover -s tests -v我实测下来是 24/24 通过其中 4 个测试专门覆盖这个 SkillGitHub 仓库 slug 与版本号规范化、Secret 和大文件阻断只报告规则与路径不泄露原值、Release Notes 与源码归档可复现、针对本地 bare remote 执行真实 commit 和普通 push 并验证远端 SHA。本地 bare remote 这点很关键它让执行路径不依赖临时公开仓库能测到真正的 Git 写入和 fetch而不是只 mock 子进程返回值。第二层是用真实仓库自发布。dry-run 的 receipt 里候选文件 58 个、候选总大小 287,679 B、blocker 0、warning 0最终分支main最终提交7a90e7e...分支校验true。对应提交包含 10 个变更文件新增 1,102 行、删除 3 行。第三层是脱离发布器再次验证也就是上面那条verify_publish.py命令输出类似{ localHead: 7a90e7eede0c5029c131d7496ee479ae8353f539, remoteBranch: 7a90e7eede0c5029c131d7496ee479ae8353f539, branchMatches: true, verified: true }branchMatches为true说明本地 HEAD 和远端分支精确一致。这里要诚实说明这次真实公开验证执行的是 branch-only 发布Release 功能已经实现并通过本地 Git 仓库闭环测试覆盖了版本、Notes、源码归档和校验和逻辑但我没有为了写文章额外创建一个没有实际版本意义的公开 Release。功能已实现和已在公开仓库创建 Release 是两回事不能混着说。5. 本篇常见错排查报错一remote branch is not ancestor of local HEAD。说明非空远端和本地不是同一段历史。默认会停止不会自动--allow-unrelated-histories也不会 force push。先确认是不是选错了目录或仓库确实要覆盖再人工处理。报错二secret detected in path:line。审计命中了.env、私钥或 Token 形态。报告只记录规则、路径和行号不复制匹配到的秘密值避免扫描报告本身变成泄露文件。把敏感文件加进.gitignore并git rm --cached后再跑。报错三file exceeds 100 MiB。GitHub 单文件硬限制是 100 MiB超过直接阻断。大文件更适合作为 Release 附件或走 Git LFS不要硬塞进普通提交。报错四tag v1.2.3 already exists。同名 Tag 已存在流程停止不覆盖。要么换版本号要么人工确认后删除旧 TagSkill 不会替你改写已有版本。报错五gh: command not found或gh auth status失败。创建 Release 依赖 GitHub CLI。装好gh后执行gh auth loginSkill 只使用系统现有登录状态不读取 Token。报错六confirm-repository mismatch。传入的--confirm-repository和实际远端 URL 不一致。这是防止推错仓库的关键检查核对OWNER/REPOSITORY拼写即可。接入和排障相关的文档可以对照看https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite。如果用的是 Claude Code 这类编码环境接入说明在https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentClaudeCodeAnthropicutm_campaignrewrite。6. 把发布链路固定成可复用能力回到最初的问题完全自动上传 GitHub最有价值的部分不是把十几条命令压成一条而是让这条命令仍然能回答——它准备上传什么为什么拒绝某个文件或远端获得了哪一层写权限有没有改写历史或远端配置Release 里每个文件来自哪个最终提交最后谁证明 GitHub 上的结果真的一致我采用的结构是一个综合 Skill 负责完整用户意图内部模块化脚本负责确定性执行dry-run 和显式参数负责权限边界独立验证器给出第二份证据。这样“全自动”不等于“遇到任何情况都继续向前”而是在边界清楚、证据充分、授权明确时把重复动作做完遇到历史冲突、秘密值或目标不一致时自动停止。如果你正在把本地工具、网页项目、Python 包或小游戏仓库整理成正式开源项目可以先按上面的config.toml和settings.json配好跑一次 dry-run。它给出的候选文件、远端历史和 Release 计划往往比直接执行一次 push 更能暴露真正的发布问题。模型对话和 API 接入从https://taotoken.net/api开始密钥在https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite管理配好之后这套四步链路就能稳定复用了。