git-operations

Git 操作 Skill

本 skill 只规定本项目里的 Git 操作边界。根 AGENTS.md 保留不可越过的红线；复杂提交、推送、PR、worktree 和 merge 细则以本文为准。

触发

用户要求以下动作时使用：

• git status、diff、commit、push。
• “检查一下没问题就提交 / 看下再推”。
• 同步 main、处理 pre-push、远端失败。
• PR、merge、fork、worktree、跨仓库写回。

基本原则

• 默认工作区可能是脏的，陌生改动先判断影响；无关就绕开，不顺手清。
• 不擅自 stash、restore、checkout --、clean、reset、rebase、revert。
• 不擅自创建、切换、删除分支或 worktree。
• Git 操作只处理用户当前授权目标，不自动升级成同步主线、修 bug、跑专项验证或整理全仓。
• 需要用户判断时先说现实含义，再给代码证据；不要只甩测试名、字段名或错误码。

看改动

日常审查顺序：

1. git status --short --branch
2. git diff --stat
3. 按目标读取关键文件 diff

审查时先把改动分类：用户可见行为、业务规则、测试/mock/fixture、生成物/evidence、文档规范、纯格式。拿不准、会恢复旧行为、触及用户刚修链路、改生产逻辑、改测试期望、影响 E2E 证据或合并裁定时，先上报现实含义和风险，不直接吞进提交。

提交

默认只提交本轮明确范围内的改动。

用户说“都提交 / 全修改 / 所有修改 / 全部改动”时，解释为审查当前仓库内已暂存、未暂存和未跟踪文件；不包含 ignored 文件。

提交规则：

• git commit -m 默认中文，标题写清业务对象和动作，不能写“修复问题 / 更新代码”。
• 大提交用中文多行消息，覆盖主要文件簇、行为变化、测试/evidence 和用户点名事项。
• 提交消息必须来自真实 diff 审查；关键改动映射不上消息时，先继续审查。
• 提交前发现待提交对象超过 10MB，先判断是否应进仓库；诊断、trace、视频、临时 evidence、构建产物、日志和压缩包默认不提交。超过 50MB 需强理由；超过 100MB 视为 GitHub 推送硬阻塞。
• 涉及 i18n 或可见文案时，首次提交前默认跑 npm run i18n:check 或等价最小检查。

提交切线：

• 当目标是“检查后提交 / 提交后 push”时，以首次提交前完成的审查和暂存范围作为本次提交切线。
• git commit 成功后新出现的未跟踪、截图、测试输出、后台产物或并发改动，默认不纳入本次提交。
• 若后续 push 的 hook 失败且必须修改当前已提交内容才能通过，才回到门禁修复路径。

推送

目标涉及 push 时，默认先 git fetch --prune origin。fetch 只更新远端跟踪信息，不等于授权 pull、merge、rebase 或 stash。

fetch 后：

• 只是 ahead N：继续推送当前提交。
• 出现 behind 或 ahead + behind：不得自动 pull / merge / rebase / stash；说明远端已有新提交，让用户选择合并主线继续当前 PR、从最新主线重开、或暂缓同步。
• 用户当轮已明确要求“处理远端更新后继续推 / 同步后再推 / 合并远端再推 / 改到能 push”时，先锁定合并方向、工作区归属和双边范围，再推进。

push 失败先分网络/协议、hook、真实测试失败、权限失败。GitHub 403 / Permission denied / Write access denied 通常表示不能直推上游主仓；贡献代码默认切 fork + PR，而不是索要上游写权限。

绕过门禁、guard 或预算限制不是默认动作；没有用户当轮明确允许，不使用 --no-verify 或 bypass 环境变量。

“检查后提交/推”的动作上限

“检查没问题 / 看下再提交 / 看下再推”默认是静态审查后 Git 动作，不等于主动跑测试，也不等于授权修复。

即使 diff 含 UI，也不得自动启动 UI 审计、截图、Playwright、E2E、构建、lint 或 typecheck。只有用户点名、Git hook 自动触发，或静态审查发现需要机器确认的具体风险，才追加命令。

如果静态审查、hook 或生成脚本暴露需要编辑代码的问题：