Vibe Coding 知识库

提交并推送所有更改 ​

注意：暂存所有更改、提交并推送到远程。仅在确信所有更改应归为一组时使用。

工作流程 ​

1. 分析更改 ​

并行运行：

  • git status - 显示已修改/已添加/已删除/未跟踪的文件
  • git diff --stat - 显示更改统计
  • git log -1 --oneline - 显示最近提交以参考消息风格

2. 安全检查 ​

检测到以下内容时停止并警告：

  • 密钥文件：.env*、*.key、*.pem、credentials.json、secrets.yaml、id_rsa、*.p12、*.pfx、*.cer
  • API 密钥：任何包含真实值（非占位符如 your-api-key、xxx、placeholder）的 *_API_KEY、*_SECRET、*_TOKEN 变量
  • 大文件：>10MB 且未使用 Git LFS
  • 构建产物：node_modules/、dist/、build/、__pycache__/、*.pyc、.venv/
  • 临时文件：.DS_Store、thumbs.db、*.swp、*.tmp

API 密钥验证： 检查修改的文件中是否存在以下模式：

bash
OPENAI_API_KEY=sk-proj-xxxxx  # ❌ 检测到真实密钥！
AWS_SECRET_KEY=AKIA...         # ❌ 检测到真实密钥！
STRIPE_API_KEY=sk_live_...    # ❌ 检测到真实密钥！

# ✅ 可接受的占位符：
API_KEY=your-api-key-here
SECRET_KEY=placeholder
TOKEN=xxx
API_KEY=<your-key>
SECRET=${YOUR_SECRET}

验证：

  • .gitignore 已正确配置
  • 无合并冲突
  • 正确的分支（如在 main/master 上则警告）
  • API 密钥仅为占位符

3. 请求确认 ​

展示摘要：

📊 更改摘要：
- X 个文件修改，Y 个添加，Z 个删除
- 总计：+AAA 行插入，-BBB 行删除

🔒 安全：✅ 无密钥 | ✅ 无大文件 | ⚠️ [警告]
🌿 分支：[name] → origin/[name]

将执行：git add . → commit → push

输入 'yes' 继续或 'no' 取消。

在执行前等待明确的 "yes"。

4. 执行（确认后） ​

按顺序运行：

bash
git add .
git status  # Verify staging

5. 生成提交消息 ​

分析更改并创建 conventional commit：

格式：

[type]: Brief summary (max 72 characters)

- Key change 1
- Key change 2
- Key change 3

类型： feat、fix、docs、style、refactor、test、chore、perf、build、ci

示例：

docs: Update concept README files with comprehensive documentation

- Add architecture diagrams and tables
- Include practical examples
- Expand best practices sections

6. 提交并推送 ​

bash
git commit -m "$(cat <<'EOF'
[Generated commit message]
EOF
)"
git push  # If fails: git pull --rebase && git push
git log -1 --oneline --decorate  # Verify

7. 确认成功 ​

✅ 成功推送到远程！

提交：[hash] [message]
分支：[branch] → origin/[branch]
更改文件数：X (+insertions, -deletions)

错误处理 ​

  • git add 失败：检查权限、锁定文件，验证仓库是否已初始化
  • git commit 失败：修复 pre-commit 钩子，检查 git 配置（user.name/email）
  • git push 失败：
    • Non-fast-forward：git pull --rebase && git push
    • 无远程分支：git push -u origin [branch]
    • 受保护分支：改用 PR 工作流

何时使用 ​

适用场景：

  • 多文件文档更新
  • 包含测试和文档的功能开发
  • 跨文件的 bug 修复
  • 项目范围的格式化/重构
  • 配置变更

避免场景：

  • 不确定要提交的内容
  • 包含密钥/敏感数据
  • 未经审查的受保护分支
  • 存在合并冲突
  • 需要细粒度的提交历史
  • pre-commit 钩子失败

替代方案 ​

如果用户想要更多控制，建议：

  1. 选择性暂存：审查/暂存特定文件
  2. 交互式暂存：git add -p 进行补丁选择
  3. PR 工作流：创建分支 → 推送 → PR（使用 /pr 命令）

请记住：推送前务必审查更改。如有疑问，使用单独的 git 命令以获得更多控制。