git-pushing-fast-cn

Git 快速提交推送

Overview

在当前仓库的当前分支上，快速、安全地提交并推送本地改动。

默认结果是一个聚焦的 Conventional Commit，再推送到当前分支跟踪的远端。对于非简单改动，需要写分段提交正文，让评审者能按主题快速理解改动内容。

这个流程适用于普通单分支交付，例如把当前工作保存到远端；不处理分支合并、历史改写或 PR 创建。

何时使用

当用户要求执行以下操作时使用本技能：

• 提交并推送当前工作
• “推上去”、“保存到远端”或完成普通单分支交付
• 将 staged 和 unstaged 改动整理为一个 Conventional Commit
• 提交正文需要按功能区、界面区、测试、文档或校验结果分段说明

不要使用

以下场景不要使用本技能：

• 需要将工作分支合并到主分支的双分支流程
• 强制推送、rebase、squash、amend 或改写历史
• 创建 Pull Request，除非用户在推送后明确要求
• 代码评审、发布说明、周报或 changelog 生成
• git reset --hard、git checkout -- <file> 等破坏性命令

使用说明

按以下流程顺序执行。目标仓库、分支或推送目的地不明确时，停止并说明阻塞原因，不要猜测执行。

1. 检查仓库状态。

   • 运行 git status --short、git branch --show-current 和 git remote -v。
   • 可用时通过 git rev-parse --abbrev-ref --symbolic-full-name @{u} 检查 upstream。
   • 先看暂存区统计：git diff --cached --stat；如果没有暂存改动，再看 git diff --stat。
   • 不得丢弃或回滚用户改动。

2. 暂存改动。

   • 用户要求提交全部改动时，执行 git add -A。
   • 用户指定更小范围时，只暂存指定范围。
   • 重新运行 git status --short，确认目标文件已经暂存。

3. 生成提交信息。

   • 使用 Conventional Commits：type(scope): 中文摘要。
   • 根据实际 diff 选择类型，常用 fix、feat、docs、refactor、test、chore、ci。
   • 标题尽量控制在 72 个字符以内。
   • 对非简单改动，提交正文必须包含 2-5 个简短分段。
   • 分段标题命名受影响区域，下面用列表说明具体变化。
   • 如果运行了测试、校验、hook 或手动验证，需要加入“测试：”或“验证：”分段。

分段正文示例：

fix(module): 调整组件行为

行为：
- 调整受影响组件的默认状态。
- 对不支持的输入保持原有行为不变。

实现：
- 将重复逻辑移动到小型辅助函数。
- 更新相关配置以使用新的辅助函数。

测试：
- 补充更新行为的覆盖用例。
- 推送前运行相关校验。

4. 提交。

   • 使用多个 -m 参数或其他无交互方式执行 git commit，确保正文被完整保留。
   • 禁止使用 --no-verify。
   • hook 或校验失败时，先修复失败原因，再重新提交。

5. 推送。

   • 当前分支已有 upstream 时，执行 git push。
   • 当前分支没有 upstream 时，执行 git push -u origin <current_branch>，除非仓库或用户指定其他远端。
   • 推送因远端更新被拒绝时，先 git fetch 并检查差异再决定下一步。
   • 除非用户明确要求强推并确认风险，否则不得 force-push。

6. 汇报。

   • 最终回复保持简洁。
   • 说明提交哈希、分支、远端推送结果和已运行的校验。
   • 如果宿主应用支持 Git 指令，仅在对应 Git 动作成功后再发出相关指令。