• Home
  • Skills
  • Projects
  • Blog
  • Contact
Resume
Naser Rasouli

Author

Naser Rasouli

Front-End developer - sharing lessons learned, notes, and write-ups from real projects.

GitHubLinkedIn

Last posts

BEM Methodology in CSS: predictable naming for clean styles
2026-02-18•1 min read

BEM Methodology in CSS: predictable naming for clean styles

A practical guide to BEM to avoid style conflicts, structure class names, and keep CSS maintainable.

Why console.log After setState Shows the Old Value
2026-02-04•1 min read

Why console.log After setState Shows the Old Value

React batches state updates, so logging right after setState prints the previous value. Here’s why and the right ways to read the fresh state.

Cleanup Functions in useEffect: Stop Leaks Before They Start
2026-02-04•1 min read

Cleanup Functions in useEffect: Stop Leaks Before They Start

A practical guide to writing cleanup in useEffect so you avoid memory leaks, duplicate listeners, and setState on unmounted components.

Conventional Commits: Write Better Git Messages

Conventional Commits: Write Better Git Messages

2025-12-12
gitconventional-commitschangelogautomation

Why commit message structure matters

Every change you ship becomes part of Git history. When messages are inconsistent, you lose context, changelogs become manual, CI/CD cannot parse intent, and teammates struggle to follow the story. Conventional Commits fixes this with a lightweight, machine-friendly format that keeps history readable for humans and tools.

What is Conventional Commits?

Conventional Commits is a simple spec for structuring Git commit messages. It enforces predictable patterns so you can automate changelogs, semantic versioning, and release pipelines while keeping the history self-explanatory.

Commit message structure

<type>(scope): <short description>
[body]
[footer]

Components

  • type (required): the kind of change (feat, fix, docs, etc.)
  • scope (optional): the area touched, e.g. auth, cart, api
  • description (required): a concise summary of what changed
  • body (optional): extra context, reasoning, or implementation notes
  • footer (optional): references and breaking changes (e.g., BREAKING CHANGE: or Closes #123)

Common commit types

Type Purpose
feat A new feature
fix A bug fix
docs Documentation-only changes
style Code formatting (whitespace, etc.)
refactor Code changes that don't fix bugs or add features
test Adding or updating tests
chore Miscellaneous tasks (build tools, etc.)

Real-world examples

Use the format consistently so teammates and tools can infer intent at a glance:

  • New feature 
    feat(cart): add quantity selector to cart items
  • Bug fix 
    fix(auth): resolve issue with token refresh on expiration
  • Documentation 
    docs(readme): update usage example for CLI
  • Styling 
    style(ui): reformat buttons and inputs using Tailwind
  • Refactor 
    refactor(api): simplify data fetch logic in product service
  • Breaking change 
    feat!: drop support for Node.js v12

Final thoughts

Conventional Commits keep your Git history structured, searchable, and automation-ready. Adopt the format across the team and you'll ship cleaner releases, clearer changelogs, and easier code reviews.