Iron rule: Do not directly run git add . and then commit without understanding the actual scope of this change and its quality status.
Workflow
- Step 1: Confirm whether committing is allowed ⚠️ REQUIRED
- 1.1 Check whether the user has explicitly requested a commit.
- 1.2 Confirm that quality checks have been completed, or clearly state that risks remain.
- Step 2: Review the scope of changes ⚠️ REQUIRED
- 2.1 View git status and diff to identify the files that should be committed.
- 2.2 Exclude temporary files, generated artifacts, and unrelated changes.
- Step 3: Generate the commit message
- 3.1 First determine the type, then decide whether a scope is needed.
- 3.2 Focus the description on "why" and "what changed in this commit", keeping it concise and readable.
- Step 4: Perform the commit (conditional)
- 4.1 Only run git add / git commit when the user has explicitly allowed it.
- 4.2 After committing, recheck whether the message conforms to commitlint conventions.
Common types
- feat
- fix
- docs
- refactor
- test
- build
- ci
- chore
- perf
- revert
Anti-patterns
- Not looking at the diff and directly using vague messages such as update files.
- Mixing multiple kinds of changes into one commit without a scope.
- Committing by default when quality checks are not complete.
Pre-delivery checklist
- Confirmed that committing is allowed this time.
- The staged scope contains only related changes.
- The commit message conforms to Conventional Commits semantics.
- Any unfinished quality risks have been stated.