commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Overview

概述

Creating clean, atomic commits that follow best practices for version control hygiene. The core principle is one logical change per commit - each commit should represent a single, coherent, easily revertable modification that can stand alone.

创建符合版本控制最佳实践的清晰、原子化提交。核心原则是每次提交对应一个逻辑变更——每个提交应代表一个独立、连贯、可轻松回滚的修改，且能独立存在。

Instructions

操作说明

ALWAYS
cd
to project root before git commands. NEVER use
git -C
. Execute git commands directly without explanatory preamble. Commit immediately without confirmation prompts (never use interactive mode).

Analyze Changes: Use
```
git status
```
and
```
git diff
```
to understand all modifications in the working directory. Categorize changes by:
- STRUCTURAL: Code reorganization, renaming, refactoring without behavior changes
- BEHAVIORAL: New features, bug fixes, functionality changes
- DOCUMENTATION: README updates, comment changes, documentation files
- CONFIGURATION: Build files, dependencies, environment settings
Group Logically: Organize changes into logical units where each unit:
- Addresses a single purpose or problem
- Structure changes to be atomic and easily revertable for safe rollback
- Would make sense to revert as a unit
Stage Changes: Use appropriate staging strategy:
- Whole file:
```
git add <file>
```
- Hunk-by-hunk:
```
git diff <file> > /tmp/patch.diff
```
  , edit the patch to keep only specific hunks, then
```
git apply --cached /tmp/patch.diff
```
- NEVER use
```
git reset --hard
```
  . To unstage, use
```
git restore --staged
```
- Fallback: If
```
git apply --cached
```
  fails (malformed patch), stage the whole file with
```
git add <file>
```
  instead
Handle Pre-commit Hooks: If hooks complain about unstaged changes:
- Stash unstaged changes first:
```
git stash push -p -m "temp: unstaged changes"
```
  (select hunks to stash)
- Or stash all unstaged:
```
git stash push --keep-index -m "temp: unstaged changes"
```
- Commit, then restore:
```
git stash pop
```
- If hooks modify staged files (auto-formatting), re-add the modified files and retry the commit
Create Atomic Commits: For each logical group:
- Write clear, descriptive commit messages following conventional format
- Keep first line under 72 characters (aim for 50)
- Include context in body when necessary
- IMPORTANT: DO NOT run any linter/formatter before committing. Commit exactly what the user changed

在执行Git命令前务必
cd
到项目根目录。绝对不要使用
git -C
。直接执行Git命令，无需前置说明。提交时立即执行，不显示确认提示（绝不使用交互模式）。

分析变更：使用
```
git status
```
和
```
git diff
```
了解工作目录中的所有修改。按以下类别对变更进行分类：
- 结构型：代码重组、重命名、不改变行为的重构
- 行为型：新功能、Bug修复、功能变更
- 文档型：README更新、注释修改、文档文件变更
- 配置型：构建文件、依赖项、环境设置变更
逻辑分组：将变更组织为逻辑单元，每个单元需满足：
- 针对单一目标或问题
- 变更结构需原子化，可轻松回滚以确保安全撤销
- 作为一个单元回滚具有合理性
暂存变更：使用合适的暂存策略：
- 整个文件：
```
git add <file>
```
- 逐块暂存：
```
git diff <file> > /tmp/patch.diff
```
  ，编辑补丁以仅保留特定代码块，然后执行
```
git apply --cached /tmp/patch.diff
```
- 绝对不要使用
```
git reset --hard
```
  。取消暂存请使用
```
git restore --staged
```
- 备选方案：如果
```
git apply --cached
```
  执行失败（补丁格式错误），则改为使用
```
git add <file>
```
  暂存整个文件
处理提交前钩子：如果钩子提示存在未暂存变更：
- 先暂存未暂存的变更：
```
git stash push -p -m "temp: unstaged changes"
```
  （选择要暂存的代码块）
- 或者暂存所有未暂存变更：
```
git stash push --keep-index -m "temp: unstaged changes"
```
- 提交后恢复：
```
git stash pop
```
- 如果钩子修改了已暂存的文件（自动格式化），重新添加修改后的文件并重试提交
创建原子化提交：针对每个逻辑单元：
- 按照规范格式编写清晰、描述性的提交信息
- 首行长度不超过72个字符（目标为50个字符）
- 必要时在正文部分添加上下文说明
- 重要提示：提交前不要运行任何代码检查器/格式化工具。完全按照用户的修改内容进行提交