Automate Git Workflow, Changelogs, and GitHub Releases

The Problem

Your team's git history is a mess. Commit messages range from "fix stuff" to "WIP" to three-paragraph essays. When a customer asks what changed in the last release, someone manually reads through 80 commits to compile a list. The changelog has not been updated since v2.1.0 (you are now on v3.4.2). Release notes on GitHub say "various bug fixes and improvements" because nobody wants to spend 30 minutes writing them. When a bug is reported, tracing which release introduced the change requires reading raw diffs because the commit messages give no useful context.

The Solution

Use git-commit-pro to enforce conventional commit messages that categorize every change, changelog-generator to automatically produce a structured changelog from those commits, and the github skill to create GitHub releases with detailed notes, manage labels, and automate the release workflow.

Step-by-Step Walkthrough

1. Standardize commit messages across the team

Adopt conventional commits so every change is categorized and traceable.

Set up conventional commit enforcement for our repo. Configure a commit-msg hook that validates the format: type(scope): description. Types should be feat, fix, perf, refactor, docs, test, and chore. Add a scope for each module (auth, billing, api, ui). Reject commits that do not follow the format and show a helpful error with examples.

Developers write feat(billing): add proration for mid-cycle upgrades instead of "billing changes." Every commit now carries machine-readable metadata about what changed and where.

2. Generate changelogs from commit history

Turn the structured commit history into a changelog grouped by version and category.

Generate a CHANGELOG.md from our git history. Group entries by version (from git tags), then by type: Features, Bug Fixes, Performance Improvements, and Breaking Changes. Include the commit scope, description, and a link to the PR. Start from tag v3.0.0 to the current HEAD.

The generated changelog groups commits into scannable sections:

# Changelog

## v3.5.0 (2026-02-18)

### Features
- **billing**: Add proration for mid-cycle plan upgrades (#412)
- **api**: Support cursor-based pagination on /orders endpoint (#408)
- **ui**: Add dark mode toggle to dashboard settings (#405)

### Bug Fixes
- **auth**: Fix token refresh race condition causing 401 on concurrent requests (#410)
- **billing**: Correct tax calculation for Canadian provinces (#407)

### Performance
- **api**: Reduce /products query time from 340ms to 45ms with composite index (#409)

### Breaking Changes
- **api**: Remove deprecated /v1/legacy-orders endpoint (#411)
  Migration: Use /v2/orders with cursor pagination instead.

## v3.4.2 (2026-02-04)
...

Each entry links to the pull request, making it easy for support engineers to find the exact code change behind any release note.

3. Automate GitHub releases on merge to main

Every merge to main that includes feat or fix commits should trigger a new release.

Create a GitHub Actions workflow that runs on merge to main. It should determine the next semantic version based on commit types (feat = minor, fix = patch, breaking change = major), generate release notes from commits since the last tag, create a git tag, and publish a GitHub release with the generated notes. Include a section for migration instructions when there are breaking changes.

4. Set up PR labeling and milestone tracking

Automatically categorize pull requests and track progress toward release milestones.

Configure GitHub to auto-label PRs based on file paths: changes in src/billing/ get the billing label, changes in tests/ get the testing label. Create a release milestone that collects all merged PRs since the last release. When a release is published, close the milestone and create the next one.

Real-World Example

A developer tools company with 6 engineers was spending 2 hours per release manually writing changelogs and release notes. After adopting git-commit-pro, the commit history became self-documenting within one sprint. The changelog generator produced a complete CHANGELOG.md covering 14 versions in under a minute. The automated GitHub release workflow shipped its first release with zero manual steps -- a developer merged a PR to main and three minutes later, v3.5.0 appeared on the releases page with categorized notes, linked PRs, and a migration guide for the one breaking change. Customer support now links to specific release notes instead of saying "it was fixed in a recent update."

Tips

• Add the commit-msg hook to the repository's pre-commit config so it installs automatically for every developer. Relying on each person to install it manually means someone will skip it.
• Use commit scopes that match your codebase modules, not arbitrary labels. If your repo has src/auth/, src/billing/, and src/api/, the scopes should be auth, billing, and api.
• Include a "Breaking Changes" section in every release, even if it is empty. This trains readers to check for breaking changes and builds trust that the changelog is comprehensive.
• Tag releases immediately after the changelog is generated to avoid a window where commits land between the changelog and the tag, creating drift.