commit

Claude 命令：提交

你的任务是创建格式规范、采用 Conventional Commits 格式并带有表情符号的提交。

说明

重要：严格按照以下步骤操作：

1. 分支检查：检查当前分支是否为 master 或 main。如果是，则询问用户是否要在提交前创建单独的分支。如果用户确认需要新建分支，则使用 <type>/<username>/<description> 模式创建分支（例如：feature/leovs09/add-new-command）
2. 除非指定了 --no-verify，否则自动运行预提交检查，例如 pnpm lint，或根据项目语言运行类似检查。
3. 使用 git status 检查哪些文件已暂存
4. 如果已暂存的文件数为 0，则自动使用 git add 添加所有已修改和新建的文件
5. 执行 git diff，了解将要提交的更改
6. 分析差异，判断是否包含多个不同的逻辑更改
7. 如果检测到多个不同的更改，则建议将其拆分成多个较小的提交
8. 针对每次提交（或未拆分时的单次提交），使用带表情符号的 Conventional Commits 格式创建提交消息

提交最佳实践

• 提交前验证：确保代码已通过 lint 检查、能够正确构建，并且文档已更新
• 原子化提交：每次提交都应包含服务于单一目的的相关更改
• 拆分大型更改：如果更改涉及多个方面，应将其拆分为多个独立提交
• 约定式提交格式：使用 <type>: <description> 格式，其中 type 为以下之一：
  • feat：新功能
  • fix：修复错误
  • docs：文档更改
  • style：代码风格更改（格式调整等）
  • refactor：既不修复错误也不添加功能的代码更改
  • perf：性能改进
  • test：添加或修复测试
  • chore：构建流程、工具等方面的更改
• 使用现在时和祈使语气：将提交消息写成命令（例如，“add feature”，而不是“added feature”）
• 首行简洁：首行保持在 72 个字符以内
• 表情符号：每种提交类型都配有适当的表情符号：
  • ✨ feat：新功能
  • 🐛 fix：修复错误
  • 📝 docs：文档
  • 💄 style：格式／风格
  • ♻️ refactor：代码重构
  • ⚡️ perf：性能改进
  • ✅ test：测试
  • 🔧 chore：工具、配置
  • 🚀 ci：CI/CD 改进
  • 🗑️ revert：撤销更改
  • 🧪 test：添加失败测试
  • 🚨 fix：修复编译器／lint 警告
  • 🔒️ fix：修复安全问题
  • 👥 chore：添加或更新贡献者
  • 🚚 refactor：移动或重命名资源
  • 🏗️ refactor：进行架构更改
  • 🔀 chore：合并分支
  • 📦️ chore：添加或更新编译文件或软件包
  • ➕ chore：添加依赖项
  • ➖ chore：移除依赖项
  • 🌱 chore：添加或更新种子文件
  • 🧑‍💻 chore：改善开发者体验
  • 🧵 feat：添加或更新与多线程或并发相关的代码
  • 🔍️ feat：改善 SEO
  • 🏷️ feat：添加或更新类型
  • 💬 feat：添加或更新文本和字面量
  • 🌐 feat：国际化和本地化
  • 👔 feat：添加或更新业务逻辑
  • 📱 feat：处理响应式设计
  • 🚸 feat：改善用户体验／易用性
  • 🩹 fix：修复非关键问题的简单补丁
  • 🥅 fix：捕获错误
  • 👽️ fix：因外部 API 更改而更新代码
  • 🔥 fix：移除代码或文件
  • 🎨 style：改善代码结构／格式
  • 🚑️ fix：关键热修复
  • 🎉 chore：启动项目
  • 🔖 chore：发布／版本标签
  • 🚧 wip：进行中
  • 💚 fix：修复 CI 构建
  • 📌 chore：将依赖项固定到特定版本
  • 👷 ci：添加或更新 CI 构建系统
  • 📈 feat：添加或更新分析或跟踪代码
  • ✏️ fix：修复拼写错误
  • ⏪️ revert：撤销更改
  • 📄 chore：添加或更新许可证
  • 💥 feat：引入破坏性更改
  • 🍱 assets：添加或更新资源
  • ♿️ feat：改善无障碍访问
  • 💡 docs：添加或更新源代码中的注释
  • 🗃️ db：执行数据库相关更改
  • 🔊 feat：添加或更新日志
  • 🔇 fix：移除日志
  • 🤡 test：模拟对象或行为
  • 🥚 feat：添加或更新彩蛋
  • 🙈 chore：添加或更新 .gitignore 文件
  • 📸 test：添加或更新快照
  • ⚗️ experiment：进行实验
  • 🚩 feat：添加、更新或移除功能标志
  • 💫 ui：添加或更新动画和过渡效果
  • ⚰️ refactor：移除无用代码
  • 🦺 feat：添加或更新与验证相关的代码
  • ✈️ feat：改善离线支持

拆分提交的指南

分析差异时，请根据以下标准考虑拆分提交：

1. 关注点不同：代码库中不相关部分的更改
2. 更改类型不同：混合了功能、修复、重构等
3. 文件模式不同：更改了不同类型的文件（例如，源代码与文档）
4. 逻辑分组：分开处理会更易于理解或审查的更改
5. 规模：非常大的更改，拆分后会更清晰

示例

优秀的提交消息：

• ✨ feat: 添加用户身份验证系统
• 🐛 fix: 修复渲染进程中的内存泄漏
• 📝 docs: 使用新的端点更新 API 文档
• ♻️ refactor: 简化解析器中的错误处理逻辑
• 🚨 fix: 解决组件文件中的代码检查警告
• 🧑‍💻 chore: 改进开发工具配置流程
• 👔 feat: 实现交易验证业务逻辑
• 🩹 fix: 修复页眉中的轻微样式不一致
• 🚑️ fix: 修补身份验证流程中的严重安全漏洞
• 🎨 style: 重新组织组件结构以提高可读性
• 🔥 fix: 移除已弃用的旧代码
• 🦺 feat: 为用户注册表单添加输入验证
• 💚 fix: 修复失败的 CI 流水线测试
• 📈 feat: 实现用户参与度分析跟踪
• 🔒️ fix: 加强身份验证的密码要求
• ♿️ feat: 提升表单对屏幕阅读器的无障碍支持

拆分提交示例：

• 第一次提交：✨ feat: 添加新的 solc 版本类型定义
• 第二次提交：📝 docs: 更新新 solc 版本的文档
• 第三次提交：🔧 chore: 更新 package.json 依赖项
• 第四次提交：🏷️ feat: 为新的 API 端点添加类型定义
• 第五次提交：🧵 feat: 改进工作线程中的并发处理
• 第六次提交：🚨 fix: 解决新代码中的代码检查问题
• 第七次提交：✅ test: 为新的 solc 版本功能添加单元测试
• 第八次提交：🔒️ fix: 更新存在安全漏洞的依赖项

命令选项

• --no-verify：跳过提交前检查（lint、build、generate:docs）

分支命名约定

在 master 或 main 上提交时，命令会询问你是否要创建新分支。如果选择是，它会按以下模式创建分支：

<type>/<git-username>/<description>

组成部分：

• <type>：提交类型（feature、fix、docs、refactor、perf、test、chore 等）
• <git-username>：你的 Git 用户名（从 git config user.name 或系统用户名获取）
• <description>：对更改的 kebab-case 描述（例如，add-user-auth、fix-login-bug）

示例：

• feature/leovs09/add-new-command
• fix/johndoe/resolve-memory-leak
• docs/alice/update-api-docs
• refactor/bob/simplify-error-handling
• chore/charlie/update-dependencies

工作流：

1. 命令检测到你位于 master 或 main 分支
2. 询问：“你当前位于主分支。是否要创建一个独立分支？”
3. 如果选择“否”：在当前分支上继续提交
4. 如果选择“是”：分析你的更改以确定类型，询问简短描述，创建分支，然后继续提交

重要说明

• 默认情况下，会运行提交前检查（pnpm lint、pnpm build、pnpm generate:docs）以确保代码质量
• 如果这些检查失败，系统会询问你是仍要继续提交，还是先修复问题
• 如果已有特定文件暂存，命令只会提交这些文件
• 如果没有文件暂存，命令会自动暂存所有已修改和新建的文件
• 提交消息会根据检测到的更改生成
• 提交前，命令会检查差异，判断是否更适合拆分为多个提交
• 如果建议拆分为多个提交，它会帮助你分别暂存并提交更改
• 始终检查提交差异，确保提交消息与更改相符