推送流程（Push Flow）

概述

本技能提供专业的代码审查与 Git 提交工作流管理。它通过系统化的提交前检查、构建验证以及对 Git 最佳实践的遵循，确保在任何代码提交前均满足质量要求。

关键规则

切勿在未经用户明确批准的情况下自动提交或推送代码。

所有 Git 操作均需在每一步获得用户确认。

提交信息（commit message）必须始终使用中文。

所有提交信息须以中文撰写，并遵循 Conventional Commits 规范（含中文描述）。

工作流决策树

当用户提及 push / commit / 提交 时：

1. 检查是否存在未提交的变更 → 若存在，进入步骤 2
2. 提供代码审查选项 → 向用户询问是否需要进行 Code Review
3. 若用户请求代码审查 → 执行全面审查
4. 生成提交信息 → 向用户展示并等待批准
5. 执行 git commit → 仅在用户批准提交信息后执行
6. 运行构建验证 → 执行 go build 确保可成功编译
7. 执行 git pull → 在推送前同步远程最新变更
8. 若 pull 拉取了新变更 → 再次执行 go build
9. 执行 git push → 仅在全部检查通过后执行

提交前工作流

步骤 1：自动提交已有变更

在进行任何代码修改前，自动提交当前所有未提交的变更：

# 检查是否存在未提交的变更
git status

# 若存在变更，则提交
git add .
git commit -m "chore: 保存当前工作进度"

注意：此为本地提交（不执行 push），用于保留进行中的工作状态。

步骤 2：提供代码审查选项

明确向用户提问：

“检测到有代码变更，是否需要进行 Code Review？”

若用户同意，则进入全面代码审查环节。

步骤 3：代码审查流程

执行系统性审查，覆盖以下维度：

代码质量：

• 逻辑正确性与边界情况处理
• 错误处理完整性
• 代码可读性与可维护性
• 性能考量

Go 特定规范：

• 是否符合 Go 编码规范
• 错误处理模式是否恰当
• Goroutine 与并发安全性
• 资源管理（如 defer 使用）

项目规范：

• 是否符合项目编码指南
• 命名规范一致性
• 注释完整性
• 测试覆盖率

安全性：

• 输入校验
• SQL 注入防护
• 敏感数据处理方式

提供可操作的反馈意见，包含具体行号引用及改进建议。

步骤 4：生成提交信息

按 Conventional Commits 格式生成简洁、准确的中文提交信息：

: 

[可选正文]

类型说明：

• feat: 新功能
• fix: 修复 bug
• refactor: 重构
• docs: 文档更新
• style: 代码格式调整
• test: 测试相关
• chore: 构建/工具相关

示例：

feat: 添加用户认证中间件

- 实现 JWT token 验证
- 添加权限检查逻辑
- 完善错误处理

向用户提交审批：

“建议的 commit message：

[commit message]

是否同意使用此 commit message？”

步骤 5：执行提交

仅在用户批准后执行：

git add .
git commit -m "[approved commit message]"

步骤 6：构建验证

在任何推送操作前，验证构建是否成功：

go build

若构建失败：

• 向用户报告错误详情
• 禁止继续执行推送
• 主动提供协助修复构建问题的支持

步骤 7：推送前拉取最新变更

推送前始终拉取远程最新变更：

git pull

若 pull 引入新变更：

• 再次运行 go build 验证兼容性
• 若构建失败，须先解决冲突再推送

步骤 8：执行推送

仅在全部检查通过后执行：

git push

文件大小与类型限制

提交前须验证：

1. 禁止提交二进制文件（除非明确要求）
2. 禁止提交大于 1MB 的文件
3. 禁止提交敏感数据（如凭据、密钥、token 等）

若检测到违规项，须向用户发出警告，并请求确认是否排除对应文件。

Git 配置偏好

远程仓库 URL 格式：始终使用 SSH 格式（git@github.com:user/repo.git），而非 HTTPS。

若检测到 HTTPS 格式的远程地址，建议转换为 SSH：

git remote set-url origin git@github.com:user/repo.git

Go 构建要求

针对 Go 项目：

• 每次提交前必须运行 go build
• 每次 pull 合并新变更后必须再次运行 go build
• 任何推送操作前必须确保编译成功

汇总检查清单

推送前请确保完成以下各项：

• 已自动提交现有变更（如存在）
• 已完成代码审查（如已请求）
• 提交信息已获用户批准
• go build 执行成功
• 已执行 git pull
• 若 pull 引入新变更，则 go build 再次执行成功
• 无二进制文件或大于 1MB 的文件
• 用户已明确批准推送操作

交互示例

用户： “帮我提交代码”

助理：

1. “检测到有未提交的代码变更，是否需要进行 Code Review？”
2. [若用户同意] 执行代码审查并提供反馈
3. “建议的 commit message：feat: 添加用户登录功能，是否同意？”
4. [用户批准后] 执行 git commit
5. 执行 go build 进行验证
6. 执行 git pull
7. [若 pull 引入新变更] 再次执行 go build
8. “所有检查通过，是否执行 git push？”
9. [用户批准后] 执行 git push

其他

1. 密码检测规则 🔒 在「关键规则」部分新增： 禁止提交包含密码的文件 提交前自动扫描敏感信息，包括： 明文密码 API keys、tokens、secrets 数据库凭证 私钥 任何敏感认证信息 若检测到敏感数据，立即中止提交并向用户发出警告 检测模式包括： password =, PASSWORD =, pwd = api_key =, secret =, token = private_key, 密码, 口令 数据库连接字符串中的凭证 JWT secrets、加密密钥

2. 多功能分离提交规则 📦 在「关键规则」部分新增： 当变更涉及多个不同功能时，必须分别提交 自动分析与分组文件： 按文件路径和模块结构分组 按相关功能分组（如认证、API、数据库、UI 等） 按逻辑功能边界分组 为每个功能组生成独立的 commit message 按顺序依次提交，而非一次性提交全部文件 示例：若变更同时包含“用户认证”和“数据导出”两个功能，则生成两个独立 commit： feat: 添加用户认证功能（认证相关文件） feat: 实现数据导出功能（导出相关文件）