Git Flow: A Branching Model for Structured Releases

This document provides a concise overview of the Git Flow branching model, designed for teams requiring structured release management and clear separation of development stages.

Core Branches

• main: Represents the official release history. All commits here are production-ready and tagged with version numbers.
• develop: The integration branch for all new features. It contains the complete history of the project, including features under development for the next release.

Supporting Branches

• feature/<feature-name>: For developing new features. Created from develop and merged back into develop upon completion.
• release/<version-number>: For preparing new production releases. Created from develop, merged into main (and tagged), and also back into develop.
• hotfix/<bug-description>: For quickly patching critical bugs in production. Created from main, merged into main (and tagged), and also back into develop.

Commit Message Guidelines

Follow a consistent format: <type>: <short commit title> (e.g., feat: add user authentication). Common types include feat, fix, docs, refactor, perf, test, build, ci, chore, revert.

Pull Requests (PRs)

PRs facilitate code review and integration. Best practices include opening early and frequent PRs, keeping them small and focused, ensuring automated checks pass, and requiring minimum approvals before merging.

Visual Overview

Refer to the diagram below for a visual representation of the Git Flow branching model:

For a more in-depth explanation, refer to the Detailed Git Flow Documentation.