Applying Alibaba Git Conventions

Commit message format:

<type>(<scope>): <description>

[optional body]

[optional footer]

Example:

fix(sku): resolve price display error on discount

The discount calculation used integer division, causing
rounding errors for prices with cents.

Fix #1023

Progress:

• Determine commit type
• Determine scope (if applicable)
• Write imperative, present-tense description
• Add body if change needs explanation
• Add footer for issue refs, breaking changes, or sign-offs
• Choose branch naming per workflow model
• Tag releases per SemVer rules (if releasing)

Step 1: Choose commit type

Note: CSS changes are usually feat or fix, not style.

Step 2: Choose scope (optional)

Scope names the affected module/feature. In monorepos, use the subpackage name:

chore(babel-helper-plugin-utils): add npmignore

Step 3: Write the description

• Present tense, not past: delete redundant docs not deleted redundant docs
• Imperative mood, no subject: not i delete redundant docs
• No capital first letter, no trailing period

Step 4: Body (optional)

Present tense, imperative mood, normal punctuation rules. Explain what and why, not how.

Step 5: Footer (optional)

Sign-offs / review trail:

Reported-by: User1 <user1@example.com>
Reviewed-by: User3 <user3@example.com>
Signed-off-by: Author <author@example.com>

Issue references — keywords: close/closes/closed, fix/fixes/fixed, resolve/resolves/resolved

• close: closes issue in current repo
• fix: closes issue (current or other repo), typically for bug fixes
• resolve: closes issue in current or other repo

Multiple issues:

Close #1, #2, #3
Fix #1, close #2, close #3

Breaking changes:

BREAKING CHANGE: renamed `size` prop values from `s|m|l` to `small|medium|large`.

Migration:
<Button size="s">Submit</Button> --> <Button size="small">Submit</Button>

Step 6: Branching strategy

Pick one model per project:

• No Flow: solo maintainer, commit directly to main.
• GitHub Flow / One Flow (recommended default for most projects): single main branch; feature/hotfix branches merge back into main; version always increments; no long-term support for old versions.
• Git Flow: multiple maintained branches with LTS-style support; use only when the project needs long-term backport support (e.g., a widely depended-on library or platform with SaaS-style release cycles).

Long-lived branches (multi-branch model):

• main: latest stable, source of hotfixes
• feature: new features, merges to main on release
• next: next major version / breaking changes, merges to main on release
• x / x.y: maintenance branch for older major versions, never merges back to main

Temporary branch naming:

<type>/[issue-id-]<description>

Examples:

feat/shopping-cart
fix/3012-crash-on-search

Step 7: Tagging releases

Must follow Semantic Versioning:

# good
v1.0.0
v1.0.0-rc.1
v1.0.0-beta.2

# bad
v1        (missing minor/patch)
v1.0      (missing patch)
v1.0.0.1  (too long)
v1.02.0   (leading zero)

Rules:

• Prefix with v (enables tab-completion of git checkout v<Tab>)
• Release tags must be created on main/master, never on feature/dev branches
• Monorepo with unified versioning: tag as normal (v1.2.3)
• Monorepo with independent package versioning: prefix with package name (@foo/bar@1.2.2)

Example 1: Input: Fixed a crash that happened when searching with empty string, related to issue #3012. Output:

fix(search): handle empty query without crashing

Fix #3012

Example 2: Input: Renamed the size prop on Button, breaking change. Output:

feat(button)!: rename size prop values

BREAKING CHANGE: `size` values changed from `s|m|l` to `small|medium|large`.
Update all Button usages accordingly.

Example 3: Input: Need to name a branch for adding a shopping cart feature, no issue tracked. Output: feat/shopping-cart