AI越来越智能了他能操作git帮你自己使用git提交和推送代码但是有时候他直接一堆一起提交没有采用原子化的方式来操作wdp-git是一个 Claude Code skill它把提交 → 发布说明 → 评审 → 推送的 git 日常实现为一条带断言校验、带安全底线、可配置的七步流程。它不是文档是一份可执行的过程规范。一起来看看是否对你有用~1. 问题域git 提交流程为什么值得工程化git 的对象模型有三个特性决定了提交流程的成本结构内容寻址且不可变commit 对象的 SHA 由内容 父指针 元数据哈希得出一旦创建历史不可篡改想改只能另起一条新历史。DAG 拓扑提交通过 parent 指针连成有向无环图。可派生语义git log、git bisect、git revert、git blame全部建立在提交是原子的、每个提交可独立理解这一假设上。于是提交是否整洁直接决定后续所有 git 操作的成本提交质量git bisect 二分revert 定点回滚逐 commit 评审一提交一事一次定位到根因提交精确回滚一个功能每个提交可独立评审一提交混杂二分到的常是无关提交回滚牵一发动全身被迫看全量 diff所以分批提交不是洁癖而是让历史 DAG 变得可被机器分析的前提。wdp-git 的整个流程都围绕产出原子提交atomic commits设计。2. 为什么用 skill 承载这套流程skill 的机制本质是在模型上下文里注入一份确定性的过程规范让 LLM 作为灵活的解释器去执行。几个工程细节description 是语义检索触发器。模型在每轮都会读 description 判断是否加载该 skill所以 description 只写触发条件、不写流程摘要——否则模型可能照着 description 走捷径跳过正文里的强制步骤。这是 skill 加载机制层面的一个已知陷阱SDOSkill Discovery Optimization。渐进式披露progressive disclosure。SKILL.md 控制在约 200 行把前缀表、模板等重内容下沉到references/按需加载。原因很工程skill 被加载就占用上下文 token频繁使用的 skill 必须保持低常驻成本。与 hook / 插件 / slash 命令的边界。hook 在 harness 层拦截事件无模型参与适合机械校验插件扩展工具集而 skill 承载需要语义判断的流程——本 skill 中大量读 diff → 分类 → 确认 → 提交环节依赖语义判断这正是 skill 的适用域。另一个硬约束塑造了整体设计本环境不支持交互式 git 命令git rebase -i、git add -p、git commit -i需要 TTY 交互无法在 Claude Code 中模拟。所有环节因此必须用非交互等价操作实现详见 4.3。3. 七步流程 git 状态机上的受控转换git 的工作区可以看作一条四态状态机工作区(dirty) → 暂存区(index) → 本地历史(HEAD) → 远程历史(origin)wdp-git 的七步就是这条链上的受控迁移每一步都带前置条件检查与后置断言步骤状态迁移前置条件后置断言0 环境检查—在仓库内、非分离 HEAD分支 / 远程信息明确1 分析与分组—有变更、已过安全扫描产出分组方案表格2 确认方案—方案存在用户明确批准3 分批提交dirty→index→HEAD逐组暂存内容与方案一致git log展示 N 个原子提交4 发布说明新增 / 更新文件releasenotes 聚合完成以docs(release)提交入库5 评审闸门—提交完成评审决策明确6 推送HEAD→origin工作区干净、不落后推送成功三层核实机制对应三处断言这也是分类凭什么可信的工程答案归类断言逐文件读git diff按 hunk 的实际语义归类。diff 是真实变更的唯一可靠载体——文件名会撒谎rename、重构、脚手架分类必须基于内容。方案断言分组表交用户确认。用户对业务语义拥有最终解释权AI 是提议者而非决策者这个断言必须是人给的。暂存断言每组git add后执行git diff --cach ed --stat校验将要进 HEAD 的内容与方案逐项一致不一致则git reset回滚重新暂存。这一步把暂存区当作可校验的中间产物防止 add 错文件产生不可预期的提交。4. 提交规范的技术设计4.1 前缀系统 提交流的类型系统feat / hotfix / bugfix / docs / refactor / perf / test / style / chore / release构成对提交做静态分类的类型系统。收益不仅是可读性还有可编程性可过滤git log --grep^feat即得全部特性增量可编排CI 可按类型触发不同流水线feat → 测试构建docs → 只发布文档semver 联动feat → MINOR、bugfix → PATCH、BREAKING CHANGE → MAJOR的映射使版本号推断可自动化release notes 维护第 5 节直接受益。前缀约定默认值写死在references/commit-conventions.md可按项目改。4.2 提交信息格式type(scope): 主题 正文可选为什么改、影响面 BREAKING CHANGE: ...仅破坏兼容时主题 ≤ 50 字符保证git log --oneline单行可读scope 模块化历史可按模块过滤正文写动机不写改动——“改了什么已经在 diff 里commit message 的价值在于补足 diff 说不出的为什么”。4.3 禁用交互式命令的非交互替代git add -p不可用后同一文件含多类改动时的 hunk 级拆分改用纯管道gitdiff--file/tmp/f.patch# 1. 导出全量补丁# 2. 人工筛选出目标类别的 hunk过滤/编辑 patchgitapply--cached/tmp/f.patch# 3. 只写入 index不动工作区git apply --cached是核心它把补丁只写进暂存区、保持工作区不变与git add -p行为等价但全程无需 TTY。拆分过于复杂时skill 的兜底策略是归入主导类别并在正文说明——不为完美拆分引入新的错误面。4.4 中文路径的编码问题git 默认core.quotepathtrue非 ASCII 路径在输出中会被转义成八进制如\346\226\207\344\273\266.txt导致中文文件名在 status/diff 中不可读。skill 统一以git -c core.quotepathfalse调用输出类命令——这是展示层的编码修复否则按文件名归类在中文项目里会直接失效。5. releasenotes.md 自动维护从提交图到发布说明维护的本质是一次聚合变换commit graph本次 N 个原子提交 → 按 type 聚类feat→✨新增 / hotfix→优化 / bugfix→修复 → LLM 语义改写commit message 面向开发者 → release notes 面向使用者 → 增量插入最新区段置顶 → 单独提交 docs(release)三个技术要点面向用户语言重写只能由 LLM 完成commit message 是给开发者的“重构认证模块”release notes 是给使用者的“现在可以保持登录更长时间”。这是纯规则代码做不好的语义转换也是 skill 选型而非 hook的另一个理由。版本号推断git tag --sort-v:refname按语义化版本排序取最新 tag据此建议下一个版本号无法确定时降级为[Unreleased]。原则是拿不准就问用户不让自动化生成错误的版本语义。增量可发布状态incrementally releasable每次流程结束仓库都处于releasenotes 已反映全部未发布变更的状态。发布动作因此被简化成一个纯 tag 操作杜绝发布前突击补 notes。在这里插入图片描述6. 评审闸门把 review 前移到变更成本最低点git 有一个关键成本模型已推送 commit 的修改成本 ≫ 未推送 commit 的修改成本未推送--amend/reset --soft直接改写历史保持线性已推送改写必须 force-push会破坏协作者基于旧 SHA 的工作共享分支上被禁止唯一安全路径是git revert追加新提交。所以评审必须发生在推送前——这正是 skill 把闸门放在第 5 步提交后、推送前的动机。评审范围用 upstream tracking 精确界定gitdiff{u}...HEAD{u}解析为上游分支引用A...B是三点语法merge-base 到 B 的差异。该表达式的语义恰好是这次推送会引入的全部变更——评审该看的内容不多不少。闸门通过 AskUserQuestion 提供四档完整代码评审 / 安全评审 / 两者 / 跳过。评审发现的问题以新提交修复——不 amend 已展示的提交保持历史原子性与可复述性。7. 安全与边界把 git 的破坏面显式封住历史不可变性决定了错误一旦推送几乎不可撤销因此安全底线被写成硬性原则force-push 风险模型--force无条件覆盖远端任何状态--force-with-lease带乐观锁仅当远端自上次 fetch 以来未变化才覆盖防止覆盖他人刚推送的提交。skill 默认完全禁止强推仅在用户明确要求且目标非保护分支时才允许--force-with-lease。敏感信息扫描提交前对每个文件跑凭据特征检测私钥头、AKIA[0-9A-Z]{16}式 key、.env/*.pem等模式。理由同样源于不可变性密钥一旦进历史光删文件没用必须git filter-repo式重写历史才能清除——这是最贵的善后只能前置拦截。保护分支拦截main / master 上直接提交会触发 AskUserQuestion引导先建功能分支。把共享主干不可直接写的工程铁律强制化。撤销与补救的边界--amend、reset --soft只允许作用于未推送提交已推送改动一律走revert。整个 skill 遵循同一原则可逆操作优先重写历史必须有明确授权。8. 可定制架构约定数据与流程分离skill 用两级配置应对不同项目的差异SKILL.md 流程层骨架基本不动 references/commit-conventions.md 约定层前缀表/格式/分支命名 → 可改 references/release-notes.md 约定层模板/版本规则 → 可改覆盖优先级仓库显式规范 本项目约定表 通用兜底。skill 在流程起始会先读 CLAUDE.md / .gitmessage / CONTRIBUTING.md有则优先遵循——保证进入陌生仓库时按仓库的规矩办事而不是强行推行自己的规范。这是 convention-over-configuration 原则的体现。9. 效果一套流程换来的确定性把流程跑起来后拿到的不是更干净的 log而是可验证的确定性历史可追溯一提交一类一事按前缀可检索、可过滤、可 bisectreleasenotes.md 永不欠账每次提交自动聚合发布时打开即用质量前置评审从可选项变成必选项问题在进主干前被抓住结果一致性同一指令无论谁来执行产出同一套规范——流程被编码进上下文而不是依赖个人习惯。10. 使用指南安装源文件在wdp-skills/wdp-git/通过软链接注册到~/.claude/skills/wdp-git/与wdp-agi同一管理模式。改源文件即改即生效无需重新安装。触发/wdp-git ← 斜杠命令 提交并推送 / commit / push ← 自然语言 整理提交记录 / 更新 release notes ← 专项指令一次完整演示假设 6 个文件待提交涉及登录、编辑器、接口三块步骤动作产出0 环境检查确认仓库 / 分支 / 远程就绪信息1 分析与分组读全部 diff按内容归类分组方案表2 确认方案AskUserQuestion用户批准3 分批提交三组各add → 核对暂存 → commit3 个原子提交4 发布说明聚合改写、置顶、单独提交releasenotes.md 更新5 评审闸门询问并执行 code-review / security-review评审结论6 推送落后先 rebase无上游-u推送成功定制改references/commit-conventions.md前缀/格式/分支命名与references/release-notes.md模板/版本规则改文件即生效仓库内若有自己的规范文件会自动优先生效。结语wdp-git 的本质是把资深工程师提交代码时的所有下意识动作——分类、核实、防呆、评审、安全——翻译成 AI 能严格执行的规范流程。git 不会替你做决定但一份好的过程规范能让每一次提交都不再靠运气。技术上的每一个取舍都服务于同一个目标让历史 DAG 可分析、让变更可追溯、让错误可撤销。关注回复需要skill私信免费发送skill技能包。