DEV Community

Majdi Zlitni
Majdi Zlitni

Posted on

Stop Writing 'Fixed Bug': Git Day-to-Day with Conventional Commits

#git #productivity #beginners

We’ve all been there. A critical bug is reported in production. You grab your coffee, crack your knuckles, and run 'git log' to trace when the issue was introduced. And what do you see?

7a3b4c9 fixed bug
1d9e2f4 updated config
9f8a7b6 wip
3c2d1e8 finally works pls
Enter fullscreen mode Exit fullscreen mode

A chaotic commit history compared side-by-side with a perfectly clean, structured Conventional Commit history

Tracking what actually happened turns into an archaeological dig. When hundreds of developers on a team all push commits with vague messages, your repository's history becomes a chaotic nightmare.

But there is a better way. Welcome to Conventional Commits.

What is a Conventional Commit?

A Conventional Commit provides a lightweight, standardized structure to your commit messages. By imposing a simple set of rules, commits become easily readable by both human developers and automated machines (like your CI/CD pipelines).

Think of it as turning your Git history from a messy journal into a structured database.

The Anatomy of a Perfect Commit

The standard format is simple but powerful:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
Enter fullscreen mode Exit fullscreen mode

Here is a real-world comparison:

❌ Bad Commit: 'fixed the token issue'

✅ Good Commit: 'fix(auth): resolve token parsing issue caused by expired JWT format'

Common Commit Types (Prefixes)

To keep things consistent, we use predefined prefixes:

  • feat: A new feature for the user or the API.
  • fix: A bug fix for the user or the API.
  • docs: Documentation-only changes (README, swagger, etc.).
  • style: Formatting, missing semi-colons, etc; no code change.
  • chore: Changes to the build process or auxiliary tools (e.g., updating dependencies).
  • refactor: A code change that neither fixes a bug nor adds a feature.
  • test: Adding missing tests or refactoring tests; no production code change.

💡 Pro Tip: Need to memorize these? Add a '.gitmessage' template to your project so every time you run 'git commit', the types are printed as comments in your editor!

🔄 Revamping Your Daily Git Workflow

Adopting Conventional Commits is more than just typing a prefix; it’s a mindset shift. Your daily workflow adjusts to prioritize clean, isolated history.

1. Branch Out

Always ensure you're starting on a clean, isolated branch from 'main'.
bash
git checkout main
git pull
git checkout -b feature/user-profile

2. Make Isolated Changes

Pitfall: Don't group unrelated changes together. If you are fixing a UI bug and adding a new database field, those belong in separate commits, and possibly separate branches. Keep your commits atomic.

3. Commit Accurately

Use the prefixes rigorously! Be descriptive but concise.

git add src/components/UserProfile.tsx
git commit -m "feat(ui): add user profile dashboard component"
Enter fullscreen mode Exit fullscreen mode

4. Rebase, Don't Merge (Usually)

When bringing your feature branch up to date with 'main', prefer rebasing over merging.

  • Merging ('git merge main') creates a "merge commit," tying two histories together. It's safe, but it makes the history look like a tangled web.
  • Rebasing ('git rebase main') plucks your commits and plays them on top of the latest 'main'. It creates a beautiful, perfectly linear history.

A diagram illustrating tracking isolated changes on a feature branch, followed by a rebase against main

git fetch origin
# Rebase your current branch onto the latest main
git rebase origin/main
# Resolve any conflicts, then force push safely:
git push --force-with-lease
Enter fullscreen mode Exit fullscreen mode

Why Go Through the Trouble?

Making your commits structured feels like extra typing at first. But the ROI is massive:

  1. Instant Context for Reviewers: Your peers instantly understand the scope and intent of your Pull Request. 'chore(deps)' tells them this is a dependency update, while 'feat(checkout)' tells them to look for new business logic.
  2. Automated Changelogs: Scripts can automatically parse 'feat' and 'fix' commits to generate pristine Release Notes instantly.
  3. CI/CD Magic: Tools like Semantic Release rely wholly on these prefixes to automate versioning and deployments (which we cover in the next article!).

Conclusion & Next Steps

Switching to Conventional Commits transforms how your team interacts with the codebase. You stop guessing what a commit does and start treating your Git history as a source of truth.

Your Challenge for Today:
Try formatting your next 3 commits using the Conventional format. See how much cleaner your 'git log' looks!

In Part 2 of this series, we will take this to the next level. We'll show you how to leverage these structured commits to completely automate your application versioning using Semantic Release.

If you found this helpful, drop a ❤️ below! How does your team structure commit messages? Let me know in the comments!

Top comments (0)