Module 8 Lesson 3: Git Flow
·DevOps

Module 8 Lesson 3: Git Flow

Master the classic enterprise workflow. Learn Git Flow—a highly structured branching strategy designed for projects with scheduled release cycles and multiple versions in the wild.

Module 8 Lesson 3: Git Flow

While the Feature Branch Workflow is great for simple apps, large enterprise projects often have hundreds of developers and complex release schedules. These projects need more structure.

Git Flow is a popular branching model that assigns very specific roles to different branches and defines exactly how and when they should interact.


1. The Core Branches

Git Flow uses two main branches to record the history of the project:

main (Production)

This branch stores the official release history. Every commit on main is a production-ready version of your software.

develop (Integration)

This is where features are integrated. It contains the complete history of the project, while main only contains the "milestones."


2. Supporting Branches

Git Flow also uses three types of short-lived branches:

Feature Branches

Created from develop. Used for new features. Merged back into develop.

Release Branches

Created from develop when you are ready for a new production release.

  • You use this branch for final polish, bug fixes, and documentation edits.
  • Once finished, it's merged into both main and develop.

Hotfix Branches

Created from main. Used to quickly fix a critical bug in production.

  • Once finished, it's merged into both main and develop.
graph TD
    Main["main (Releases)"]
    Develop["develop (Active Dev)"]
    Features["feature/*"]
    Releases["release/*"]
    Hotfixes["hotfix/*"]
    
    Develop --> Features
    Features --> Develop
    Develop --> Releases
    Releases --> Main
    Releases --> Develop
    Main --> Hotfixes
    Hotfixes --> Main
    Hotfixes --> Develop

3. When to use Git Flow

Use Git Flow if:

  • You have scheduled release cycles (e.g., "We release every first Monday of the month").
  • You need to support multiple versions of your software in production at once.
  • You have a large team and need strict rules to prevent chaos.

Avoid Git Flow if:

  • You practice "Continuous Delivery" (releasing code multiple times per day).
  • You are a small, agile team. Git Flow can feel "heavy" and slow because of all the required merges.

Lesson Exercise

Goal: Trace the Release path.

  1. Imagine you are working in a Git Flow environment.
  2. You just finished a feature feature/search-engine. Where do you merge it? (develop).
  3. Your team decides it's time for "Version 2.0." What branch do you create from develop? (release/v2.0).
  4. While testing the release, you find a small UI bug. Where do you fix it? (On the release/v2.0 branch).
  5. The release is perfect. List the two branches that release/v2.0 must be merged into. (main and develop).

Observation: You'll see that Git Flow is like a well-oiled machine. It has a lot of moving parts, but it ensures that every piece of code has a clear home and a clear path to production.


Summary

In this lesson, we established:

  • Git Flow uses main for production and develop for integration.
  • Feature, Release, and Hotfix branches serve specific, short-term purposes.
  • It is excellent for structured, versioned releases but can be overkill for smaller projects.

Next Lesson: If Git Flow is the "Enterprise" way, what is the "Modern Web" way? Welcome to Lesson 4: GitHub Flow.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn