Master Your Git Workflow: A Guide to Conventional Commits and Squash Merging

Using a standardized commit convention transforms a messy git log into a readable, searchable, and automatable project history. This guide covers the essential commit types, the mechanics of committing, and how to handle "Squash and Merge" workflows.

1. The Standard Commit Types

Using the correct type helps the team immediately understand the impact of a change at a glance.

Type Purpose Example

feat Adding new functionality to the software. feat: add support for biometric login

fix Repairing a bug or unintended behavior. fix: resolve race condition in database pool

ui Visual updates, CSS changes, or interface styling. ui: update dashboard to high-contrast theme

docs Modifications to documentation or comments only. docs: update Linux installation requirements

refactor Code changes that improve quality without changing logic. refactor: modularize payment processing

chore Maintenance tasks like dependencies or build configs. chore: upgrade node version to 20.x

2. Performing a "Squash and Merge"

In many team environments, developers use Squash and Merge when closing a Pull Request. This process takes all the individual, messy commits from a feature branch and compresses them into a single, high-quality commit on the main branch.

Why Squash?

Individual development commits are often noisy (e.g., "typo fix," "still testing"). Squashing allows you to replace that noise with one clean, conventional message that represents the entire body of work for that feature.

How to do it via PowerShell:

If you are merging a feature branch named new-login into main:

1. Switch to the target branch:

`git checkout main`

1. Merge with the squash flag:

`git merge --squash new-login`

1. Finalize with a conventional commit:

`git commit -m "feat: implement complete multi-factor authentication system"`

3. Maintaining the CHANGELOG.md

Maintaining a manual log ensures you have a curated narrative of your project's progress. Use the following format to document your releases clearly.

Sample Manual Changelog Entry

1.2.0 (2026-01-29)

Summary

This release introduces biometric authentication and significantly improves the mobile dashboard experience.

• Contributors: John Doe, Alex Smith, Riley Brown, Casey White

Added

• feat: add support for biometric login (FaceID/TouchID)

• feat: implement endpoint for user analytics export

Fixed

• fix: resolve race condition in database connection pool

• fix: corrected layout shifting on the login page for iOS devices

Changed

• ui: update dashboard sidebar to use high-contrast theme

• refactor: modularize payment processing logic to improve speed

Documentation

• docs: updated Linux installation requirements in README.md

`
# 1.2.0 (2026-01-29)

### Summary
This release introduces biometric authentication and significantly improves the mobile dashboard experience.
* **Contributors:** John Doe, Alex Smith, Riley Brown, Casey White

### Added
* **feat:** add support for biometric login (FaceID/TouchID)
* **feat:** implement endpoint for user analytics export

### Fixed
* **fix:** resolve race condition in database connection pool
* **fix:** corrected layout shifting on the login page for iOS devices

### Changed
* **ui:** update dashboard sidebar to use high-contrast theme
* **refactor:** modularize payment processing logic to improve speed

### Documentation
* **docs:** updated Linux installation requirements in README.md

`

Key Takeaway

By combining Conventional Commits with Squashing, your main branch history stays pristine. This makes writing the Changelog a simple task of reviewing your clean merge commits and listing the contributors involved in the release.