mcpField
W
woocommerce-git-commit

woocommerce-git-commit

github.com/woocommerce开发10.6k118 次安装今天更新
代码仓库

关于 woocommerce-git-commit

为 WooCommerce 仓库提交未提交更改提供流程指导，面向需要组织变更并撰写提交信息的开发者。它包括差异分析、提交分组、预览和执行，以及变更日志条目的处理规则。

主要功能

  1. 01检查分支状态与变更差异
  2. 02判断提交分组方式
  3. 03拟定简洁的祈使式提交信息
  4. 04按指定文件暂存并执行提交
  5. 05说明变更日志条目格式

适用场景

  1. 01整理未提交更改并准备提交
  2. 02将无关变更拆分为多个提交
  3. 03为 WooCommerce 包编写变更日志条目

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/woocommerce/woocommerce --skill woocommerce-git-commit

安装后在 Claude Code 中输入/woocommerce-git-commit确认已加载。

详细介绍

提交更改

提交未提交的工作，并使用清晰、符合惯例的提交消息。适当时，将无关更改分成不同的提交。

动态上下文

  • 当前分支：!git branch --show-current
  • 未提交的更改：!git status --short
  • Diff 统计：!git diff --stat
  • 已暂存的 Diff 统计：!git diff --cached --stat

流程

1. 分析更改

根据上述动态上下文，确定更改内容：

  • 没有更改？ 停止——告知用户没有内容需要提交。
  • 已有暂存内容？ 保留用户暂存的内容。仅考虑未暂存的文件，以便进行额外提交。
  • 仅当统计摘要含义不明确时，才读取文件的完整 Diff。
2. 决定提交分组

默认使用单个提交，除非更改明显无关。仅在以下情况下拆分：

  • 更新日志条目与源代码更改同时存在（更新日志 = 单独提交）
  • 混合了明显独立的更改（例如，Bug 修复和无关的配置更改）

两个文件因同一原因而更改 = 一个提交。不要过度拆分。

3. 起草提交消息

利用当前会话上下文了解完成了什么工作以及原因。如果查看 Diff 和对话后仍不清楚动机，请根据 Diff 和提交惯例推断最合理的描述。

格式——以动词开头，使用祈使句，少于 72 个字符：

  • Fix get_item_downloads() not always returning an array
  • Add cache priming to AJAX downloadable search
  • Update email editor reset action label for consistency
  • Refactor order count cache refresh logic
  • Remove deprecated payment gateway fallback

动词：Fix、Add、Update、Refactor、Remove、Restore、Bump、Prepare、Simplify、Improve、Replace

仅包含更新日志的提交：Add changelog entries for [description]

不要包含 Issue 或 PR 引用——GitHub 会在 Squash 合并时添加这些内容。

如果提供了 $ARGUMENTS，请将其作为提交消息的指导。

4. 预览

执行前说明每个拟议的提交：

Commit 1: Fix double margin-top in flex layout
  files: src/Blocks/EmailEditor/Layout.php
         src/Blocks/EmailEditor/styles.css

Commit 2: Add changelog entries for email editor fix
  files: plugins/woocommerce/changelog/fix-email-margin
5. 执行

对于每个已确认的提交：

git add <specific files>
git commit -m "<message>"

始终暂存指定文件——绝不要使用 git add -A 或 git add .。

完成所有提交后，显示 git log --oneline -n <number of new commits> 以确认。

更新日志条目文件

在每个受影响的包下创建一个条目，路径为 <package>/changelog/。交互式命令 pnpm --filter=<project> changelog add 会提示输入相关内容，因此可以使用其选项以非交互方式运行（-s 表示重要性，-t 表示类型，-e 表示条目，-c 表示备注，-f 表示文件名）：

pnpm --filter=<project> changelog add --no-interaction -s patch -t fix -e "One user-facing sentence."

也可以直接按以下格式编写文件：

  • Significance: — patch、minor 或 major。
  • Type: — 包的 composer.json 中 extra.changelogger.types 声明的一种类型。对于 WooCommerce Core：fix、add、update、dev、tweak、performance、enhancement。
  • 正文——空一行后写一句面向用户的话，描述商家能看到的更改。这段内容会出现在版本更新日志中，因此应简短，并省略问题编号、PR 链接和实现细节。
  • Comment: — 仅用于不包含正文的条目，以说明为何没有面向用户的内容。几乎总是与 Type: dev 配套使用。绝不要与正文同时使用，也不要用它记录问题引用。

包含面向用户更改的条目：

Significance: patch
Type: fix

Restore the "Browse store" link on the empty cart page.

没有需要告知商家的内容的条目：

Significance: patch
Type: dev
Comment: Remove real sleep() calls from PHP unit tests; no production change.

各字段的具体填写内容——阅读对象、长度要求和审核标准——请参阅仓库根目录 AGENTS.md 的 Changelog Entries 部分。

不要将 Comment: 与拉取请求模板中的 “Comment required below” 字段混淆。前者属于 PR 表单，与更新日志文件无关。

未涉及任何包的更改（例如 .ai/skills/ 或 AGENTS.md）无需添加条目。

约束

  • 不添加 Co-Authored-By 行或自我署名
  • 绝不推送到远程仓库
  • 绝不使用 git add -A 或 git add .
  • 不要运行提交前的 lint/测试检查——这些由 woocommerce-dev-cycle 技能处理。应在调用此技能之前运行 lint，而不是之后。对于 PHP 更改，必须等此技能的 PHP lint 通过后才能提交（警告会导致 CI 失败）。

评论

支持 Markdown