Git Push

一键推送 GitHub

功能说明

把当前项目一键推送到 GitHub，覆盖完整生命周期：

• 首次推送 — 新项目从零到 GitHub
• 日常更新 — 改了文件，推一下（commit + push）
• 版本发布 — 打 tag + 创建 Release，可附带下载文件

核心原则：安全第一。宁可多问一句，不能把不该推的东西推上去。

工作流程

第0步：环境检查 + 模式判断

依次检查前置条件，任一不满足就终止并给出指引：

1. git 是否安装

• ❌ → 提示：brew install git，终止
• ✅ → 继续

2. gh CLI 是否安装

• ❌ → 提示：brew install gh，终止
• ✅ → 继续

3. gh 是否已登录 GitHub

• 执行 gh auth status 检查
• ❌ 未登录 → 提示：gh auth login，终止
• ✅ 已登录 → 记录账号名，告诉用户"当前登录账号：[xxx]"，继续

4. git 用户信息是否配置

• 执行 git config user.name 和 git config user.email 检查
• ❌ 未配置 → 提示用户设置：

  git config --global user.name "你的名字"
  git config --global user.email "你的邮箱"
  

  终止
• ✅ 已配置 → 继续

5. 当前目录是否已是 git 仓库 → 决定走哪条路

不是 git 仓库 → 【首次推送】从第1步开始
是 git 仓库，无 remote → "本地有 git 但没关联远程"
    → 先执行第1步的大文件扫描（确保安全）
    → 再跳到第2步关联远程
是 git 仓库，有 remote → 【已有仓库】进入模式选择：
    ├── "推日常更新" → 跳到第3B步（日常更新）
    ├── "发新版本"   → 检查是否有未提交的变更
    │   ├── 有变更 → 先走第3B步，再走第4步
    │   └── 无变更 → 直接跳到第4步（只打 tag + Release）
    └── "重新来"
        → ⚠️ 警告："这将删除所有 Git 历史记录（包括所有提交、分支、tag），不可恢复。"
        → 用户二次确认后删除 .git，从第1步开始

第1步：项目扫描 + .gitignore 生成

⚠️ 铁律：.gitignore 必须在第一次 git add 之前就位。绝不能先提交再排除——Git 历史里的大文件删不干净，会导致仓库臃肿、推送失败。

1.1 扫描目录大小

用 du -sh 扫描所有顶级目录和文件，按大小排序。

大文件分级处理：

展示格式（示例）：

扫描发现以下内容超过 10MB：

  1. 109MB  slides/   （PPT + 大图片）
  2.  12MB  assets/   （视频文件）

⚠️ 其中 slides/ 超过 50MB，推送会很慢。
❌ 其中 recording.mp4 (150MB) 超过 GitHub 100MB 单文件限制，必须排除。

要排除哪些？（输入序号，或 "全部排除" / "全部保留"）

1.2 敏感内容扫描（仅公开仓库）

如果用户选了公开仓库，额外扫描：

• .env / .env.* — 环境变量/密钥
• *secret* / *credential* / *token* — 密钥文件
• *.pem / *.key — 证书文件
• memory/ / MEMORY.md — AI 工具记忆文件
• 任何看起来像私人内容的文件

列出建议排除项，让用户逐项确认。

1.3 生成或更新 .gitignore

如果不存在 .gitignore：基于扫描结果生成新文件。

如果已存在 .gitignore：读取现有内容，将新增排除项合并进去，展示差异让用户确认。不覆盖用户已有的规则。

基础模板：

# macOS
.DS_Store
.AppleDouble
.LSOverride
._*

# Editor
*.swp
*.swo
*~
.vscode/
.idea/

# [以下根据扫描结果动态生成]
# 大文件（用户确认排除）
[路径1]
[路径2]

# 敏感内容（仅公开仓库时）
[路径3]

展示给用户确认后写入文件。

第2步：用户决策

1. 仓库名（默认：当前目录名）

2. 描述（一句话，可留空）

3. 公开 / 私有

• 公开 → 二次确认："公开仓库所有人可见，确认 .gitignore 已排除敏感内容？"
  • 不确认 → 回到第1.2步（敏感内容扫描）重新审查，完成后回到本步骤继续

4. 检查同名仓库

• 执行 gh repo view [账号]/[仓库名] 检查
• ❌ 不存在 → 继续
• ✅ 已存在 → 告诉用户，问：
  • "换个名字" → 重新输入
  • "用这个已有仓库" → 跳过创建，直接关联 remote（记录仓库 URL 供第3步使用）
  • "删掉重建" → 需用户二次确认

第3步：推送

3A. 首次推送（新项目）

按以下顺序严格执行：

1. git init + git branch -m main
2. git add -A
3. git commit -m "init: 初始化 [仓库名]"
4. 创建远程仓库（如果第2步中仓库不存在）：
   gh repo create [仓库名] --private/--public --description "[描述]" --source=. --remote=origin
   （如果第2步中用户选了"用已有仓库"，跳过创建，直接：git remote add origin [已有仓库URL]）
5. git push -u origin main

3B. 日常更新（已有仓库）

1. 扫描变更：git status 查看改了什么
2. 检查新增大文件：
   - 新增文件中有 >10MB 的 → 问用户确认
   - 新增文件中有单文件 >100MB → 必须排除，加入 .gitignore
   - 如果修改了 .gitignore，确保 .gitignore 本身也在后续的 git add 范围内
3. git add -A
4. git commit -m "[根据变更内容自动生成提交信息]"
   - 提交信息规则：简洁明了，一句话概括主要变更
   - 示例："update: 新增用户模块 + 修复登录 bug"
5. git push

推送失败处理

第4步：可选 — 版本发布（Release）

触发时机

• 首次推送后，主动问一次"需要打版本吗？"
• 日常更新后，不主动问（避免打扰）
• 用户主动说"发版本"、"打 release"、"打 tag"

流程

1. 确定版本号

读取当前已有的 tag（git tag --sort=-v:refname | head -5）

├── 没有任何 tag → 建议 v0.1.0
└── 已有 tag → 显示最近的版本，建议下一个（默认 minor +1）
    - v0.1.0 → 建议 v0.2.0
    - v1.2.3 → 建议 v1.3.0
    - 用户可自定义输入任意版本号

版本号说明（供用户参考）：
- v0.1.0 → v0.2.0  小更新（加了功能、改了内容）
- v0.2.0 → v1.0.0  大里程碑（首次正式发布、重大重构）
- v1.0.0 → v1.0.1  修修补补（修了个 bug）

2. Release 说明

• 自动读取自上个 tag 以来的 commit 记录（git log [上个tag]..HEAD --oneline）
• 生成变更摘要，让用户确认或修改
• 如果是第一个版本（无历史 tag），用所有 commit 生成摘要

3. 是否附带下载文件

需要附带可下载文件吗？（如 App 安装包、工具压缩包等）

├── 不需要 → 只打 tag + 创建 Release 页面
└── 需要 → 用户提供文件路径
    └── 检查文件是否存在 → 不存在则提示重新输入

4. 执行

git tag [version]
git push origin [version]
gh release create [version] --title "[仓库名] [version]" --notes "[Release 说明]"
# 如果有附件：
gh release upload [version] [文件路径]

Release 失败处理：

• tag 已存在 → 提示用户"这个版本号已被使用"，让用户换一个
• 附件文件不存在 → 提示重新输入路径
• 其他错误 → 显示错误信息

完成输出

✅ 推送完成！

- 仓库：[URL]
- 可见性：私有 / 公开
- 文件数：[N] 个
- 仓库大小：[X]
- 排除项：[列出被 .gitignore 排除的内容]
- Release：[版本号 + URL] / 未创建

核心原则

1. 扫描先于一切

.gitignore 在第一次 git add 之前就位。大文件一旦进入 Git 历史，即使后来删除，仓库体积也不会缩小，会导致推送失败或极慢。已有 git 但未关联远程的项目，也要先扫描再推送。

2. 大文件主动拦截

10MB 以上主动问用户。50MB 以上警告慢，100MB 单文件是 GitHub 硬限制必须排除。日常更新时也要检查新增文件大小。

3. 公开仓库双重检查

公开仓库额外扫描敏感内容（密钥、AI 记忆文件、私人文档），并在推送前二次确认。

4. 不破坏已有内容

如果项目已有 .git 或 .gitignore，默认不覆盖，先问用户。删除 .git 等破坏性操作必须明确警告后果并二次确认。

5. 每一步可中断

用户随时可以说"停"或"回到上一步"。不要一口气跑完不给用户反应的机会。

6. 日常更新要轻

日常更新不问 Release、不问仓库名、不重新扫描全项目。只检查新增大文件，commit + push，快进快出。

使用示例

场景1：新项目首次推送

用户：帮我推到 GitHub

Skill：
→ 检查环境：git ✅ gh ✅ 已登录 ✅ git 用户已配置 ✅ 不是 git 仓库
→ 扫描项目...发现超过 10MB 的内容：
  - 85MB slides/ → 用户确认排除
  - 15MB images/ → 用户确认保留
→ 生成 .gitignore，用户确认
→ 仓库名：my-project，私有
→ 初始化 + 推送成功
→ "需要打 Release 吗？" → 跳过
→ ✅ 完成

场景2：日常更新

用户：推一下

Skill：
→ 检测到已关联远程仓库
→ 扫描变更：修改 3 个文件，新增 2 个文件（均 <10MB）
→ 提交信息："update: 新增用户模块 + 更新配置文件"
→ 推送成功
→ ✅ 完成

场景3：发版本

用户：打个 release

Skill：
→ 当前最新 tag：v0.1.0
→ "建议下一个版本号 v0.2.0，可以吗？"
→ 自动生成变更摘要（基于 commit 记录）
→ "需要附带下载文件吗？" → 不需要
→ 创建 tag + Release
→ ✅ Release v0.2.0 发布成功！

场景4：推送时发现大文件

→ git push 失败：file recording.mp4 exceeds 100MB
→ "recording.mp4 (150MB) 超过 GitHub 限制，需要排除"
→ 加入 .gitignore，重新提交推送
→ ✅ 成功

场景5：日常更新时新增大文件

用户：推一下

→ 扫描变更...发现新增文件：
  - demo.pptx (25MB)
→ "这个文件 25MB，确认要推吗？"
→ 用户确认排除 → 加入 .gitignore
→ 推送成功
→ ✅ 完成

场景6：发版本但没有新变更

用户：打个 release

→ 当前没有未提交的变更，直接进入版本发布
→ 当前最新 tag：v0.2.0
→ "建议 v0.3.0，可以吗？"
→ 用户自定义输入 v1.0.0
→ 生成变更摘要 + 创建 Release
→ ✅ Release v1.0.0 发布成功！