Phase 5: Advanced & Professional Skills

Git hooks, conventional commits & changelog generation

Beginner ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're part of a busy kitchen crew, cooking up lots of different dishes (which are like the parts of a computer program). If everyone just cooks however they want, forgets to taste their food, or writes down their recipe changes in a super messy way, soon no one knows what's going on! The head chef (or the person in charge of the program) wouldn't know which dishes are ready, which ones have been fixed, or what new ingredients have been added. It would be a big, confusing mess.

To keep things running smoothly, we have some special "kitchen rules" and "assistants." First, imagine little robot assistants called Git hooks. These robots automatically check your work at different points. For example, one robot might always taste your dish (pre-commit) before you even write it down as a finished recipe, just to make sure it's perfectly seasoned and ready. Another robot might automatically update a big "Today's Specials" board (post-merge) in the restaurant lobby as soon as a new dish has been officially added to the main menu. They help make sure everyone follows the same quality steps.

Then there are conventional commits. This is like agreeing that every time you make a change to a dish – whether it's adding a new ingredient or fixing a cooking mistake – you write it down on a tiny recipe card in a super clear and standardized way. Instead of just writing "Changed stuff," you'd write something like "NEW DISH (desserts): Baked apple pie" or "FIXED (oven): Repaired broken light." This specific way of writing helps everyone quickly understand what kind of change was made. "NEW DISH" (like feat in coding) means you added something completely new, and "FIXED" (like fix) means you corrected a problem.

Why do we go to all this trouble with robots checking things and writing super clear recipe cards? Because it makes something called a changelog incredibly easy to create! A changelog is like that automatic "Today's Specials" board in the lobby. Because all the little recipe cards are written in the same clear way, a special assistant can just read them all and automatically put together a perfect, up-to-date list of every new dish, every fix, and every improvement that's happened in the kitchen recently. No one has to manually type out a long list of changes!

So, when you're building your own awesome computer programs with friends, using these smart "kitchen systems" means your project will stay neat, organized, and super easy for everyone to understand. You won't ever have to guess what someone else cooked up, and you'll always have a clear, automatically updated list of all the cool new things your team has brought to the table!

As a frontend developer, understanding how to maintain a clean, organized, and collaborative codebase is crucial. Git hooks, conventional commits, and changelog generation are powerful tools that help you achieve this by automating checks, standardizing communication, and streamlining release management. Git hooks are custom scripts that run automatically at specific points in your Git workflow, like before you commit (pre-commit) or after you merge (post-merge). They allow you to enforce rules, such as ensuring all code passes linting checks, running tests, or even validating your commit message format, keeping your project consistent and free of common errors across your team.

Building on this, conventional commits provide a standardized way to write your commit messages, making your project's history much easier to read and understand. Instead of vague messages like "updates," conventional commits follow a specific structure, typically type(scope): description (e.g., feat(auth): add user login functionality or fix(ui): correct button styling bug). Common types include feat (for new features), fix (for bug fixes), docs (for documentation changes), and chore (for routine maintenance). This structure clearly communicates the purpose of each change, helping both your future self and your teammates quickly grasp the impact of a commit.

The real power of conventional commits shines when combined with automated changelog generation. Because your commit messages are structured and consistent, tools can automatically parse your Git history and generate a detailed CHANGELOG.md file. This file lists all significant changes between releases, categorized by type (features, bug fixes, etc.), providing a clear and up-to-date record for users and fellow developers. Together, Git hooks, conventional commits, and changelog generation create a robust system that improves code quality, simplifies collaboration, and makes releasing new versions of your frontend applications much smoother.

Key Takeaways

  • Git hooks automate tasks like linting or testing at specific Git lifecycle events, enforcing code quality and standards.
  • Conventional commits standardize your commit messages using types (e.g., feat, fix) for clear, readable project history.
  • Structured commit messages enable automated changelog generation, creating an up-to-date record of project changes.
  • These practices enhance collaboration, improve code maintainability, and streamline release management for frontend projects.

Code Example

bash
# .git/hooks/pre-commit
#!/bin/sh

# Get the commit message from the temporary file Git provides
COMMIT_MSG_FILE=$(git rev-parse --git-dir)/COMMIT_EDITMSG
COMMIT_MSG=$(cat "$COMMIT_MSG_FILE")

# Check if the commit message starts with "feat:", "fix:", or "chore:"
# This enforces a basic conventional commit structure.
if ! echo "$COMMIT_MSG" | grep -Eq "^(feat|fix|chore):"; then
  echo "\nError: Your commit message must follow a conventional format." # Newline for readability
  echo "It should start with 'feat:', 'fix:', or 'chore:', e.g.:"
  echo "  feat: Add new user profile page"
  echo "  fix: Resolve bug in login form validation"
  echo "  chore: Update dependencies"
  echo "\nCommit aborted. Please amend your commit message." # Newline and clearer message
  exit 1 # Prevent the commit from happening
fi

How this code works

This script acts as a gatekeeper, running automatically every time a commit is attempted in Git. Its primary job is to enforce a consistent "conventional commit" message format, ensuring that every commit message starts with specific keywords like feat:, fix:, or chore:. This helps keep a project's history readable and makes it easier to track changes and automatically generate changelogs later on. The script first retrieves the message the user has typed for their commit and then checks if it matches one of the allowed patterns, only permitting the commit to proceed if the format is correct.

To achieve this, the script first locates the temporary file containing the commit message using git rev-parse --git-dir to find Git's internal directory, then reads the message into the COMMIT_MSG variable. The core logic resides in the if ! echo "$COMMIT_MSG" | grep -Eq "^(feat|fix|chore):"; then line. Here, grep -Eq searches the commit message for the required prefixes. The ! before echo means the if condition is true if the pattern is NOT found. If the message doesn't conform, echo commands display clear error instructions. Crucially, the exit 1 command is called, which aborts the commit process entirely, preventing any improperly formatted message from being recorded in the repository.

Resources

Related Articles

Hand-picked reads to go deeper on git & version control.

Back to Frontend Developer Roadmap