GitFlow vs GitHub Flow vs Trunk-Based Development & Production Hotfix

These topics are closely related because the way you handle a production hotfix depends on the branching strategy your team follows.

1. GitFlow vs GitHub Flow vs Trunk-Based Development

What are they?

All three are approaches for organizing Git development, but they differ mainly in branch structure, integration frequency, and release process.

GitFlow

GitFlow is a structured branching model with dedicated branches for development, releases, and hotfixes.

main
 |
 +---------------- hotfix/*
 |
develop
 |
 +---- feature/*
 |
 +---- release/*

Typical branches:

main
develop
feature/*
release/*
hotfix/*

It is useful when releases are planned and need a separate stabilization phase.

GitHub Flow

GitHub Flow is a simpler branch-and-Pull-Request workflow.

main
 |
 +---- feature/login
          |
          PR
          |
          v
        main
          |
        Deploy

There is normally no permanent develop branch.

Typical workflow:

main
 ↓
Create short-lived branch
 ↓
Develop
 ↓
Push
 ↓
Pull Request
 ↓
Review + CI
 ↓
Merge into main
 ↓
Deploy

Trunk-Based Development

Trunk-Based Development emphasizes developers integrating small changes very frequently into a single primary branch:

main / trunk

Developers may commit directly under appropriate controls or use extremely short-lived branches:

main
 |
 +-- small branch --+
 |                  |
 +<-----------------+
 |
 +-- small branch --+
 |                  |
 +<-----------------+

Long-lived branches are deliberately avoided.

Feature flags are commonly used to prevent incomplete functionality from being exposed.

Comparison

Feature	GitFlow	GitHub Flow	Trunk-Based
Primary branch	`main`	`main`	`main` / trunk
`develop` branch	Yes	No	No
Feature branches	Yes	Yes	None or very short-lived
Release branches	Yes	Usually no	Usually no
Hotfix branches	Yes	Can use short-lived fix branch	Can use very short-lived fix branch
Pull Requests	Common	Central to workflow	Depends on team implementation
Integration frequency	Lower	Frequent	Very frequent
Branch lifetime	Can be longer	Short	Very short
Feature flags	Optional	Useful	Commonly important
CI/CD suitability	Supported, but more branch-heavy	Strong fit	Strong fit
Complexity	Higher	Lower	Low branch complexity, but requires strong engineering discipline

Practical Example

Suppose your team is developing an e-commerce application.

The next features are:

Login
Payment
Order Tracking

Using GitFlow

main
 |
develop
 |\
 | +---- feature/login
 |
 +------ feature/payment
 |
 +------ feature/order-tracking

Features are merged into develop.

When preparing version 2.0:

develop
   |
   +---- release/2.0
             |
             +----> main
             |
             +----> develop

Using GitHub Flow

Each feature starts from main:

main
 |
 +---- feature/login
 |          |
 |          PR
 |          |
 +<---------+
 |
 +---- feature/payment
            |
            PR
            |
 +<---------+

After review and CI checks, the change is merged into main.

Using Trunk-Based Development

Changes are kept small and integrated frequently:

main
 |
 +-- login validation
 |
 +-- login API
 |
 +-- payment validation
 |
 +-- payment API
 |
 +-- order tracking

If the payment feature isn't ready for users, it can be protected using a feature flag:

if (featureFlags.NewPaymentEnabled)
{
    // New payment functionality
}

The code can exist in main while:

NewPaymentEnabled = false

Which one should you explain in an interview?

Avoid saying that one strategy is universally superior. The choice depends on the team's release model.

A practical distinction is:

GitFlow
   ↓
More branch structure
   ↓
Planned/versioned releases

GitHub Flow
   ↓
Branch + PR + main
   ↓
Simple continuous delivery workflow

Trunk-Based
   ↓
Very frequent integration
   ↓
Small changes + strong CI

2. How would you handle a Production Hotfix?

What is a Production Hotfix?

A production hotfix is an urgent fix for a serious problem in the currently deployed production application.

Examples include:

Login suddenly failing
Payment processing error
Critical API failure
Security vulnerability
Application crash
Incorrect production configuration/code behavior

Suppose production currently runs:

v2.0

and a critical payment bug is discovered.

The important rule is:

Start the fix from the code that represents the current production version.

Exactly how this is done depends on the branching/release model.

Production Hotfix Using GitFlow

GitFlow has an explicit hotfix/* branch.

Suppose:

main → v2.0

while developers are already working on version 3:

develop → future v3.0

The production bug must be fixed without accidentally deploying unfinished v3.0 work.

Step 1 — Start from `main`

git switch main
git pull origin main

Step 2 — Create hotfix branch

git switch -c hotfix/2.0.1

Now:

main (v2.0)
 |
 +---- hotfix/2.0.1

Step 3 — Fix the problem

Modify the code and test it.

git add .
git commit -m "Fix production payment issue"

Push:

git push -u origin hotfix/2.0.1

Step 4 — Create Pull Request

Even though it is urgent, normal controls should be preserved where feasible:

hotfix/2.0.1
      ↓
Pull Request
      ↓
Code Review
      ↓
Build
      ↓
Automated Tests
      ↓
Approval
      ↓
main

Urgent does not mean skipping testing and review.

Step 5 — Merge into `main`

After approval:

main
 |
 +---- hotfix/2.0.1
 |          |
 |          Fix
 |          |
 +<---------+
 |
main

Production now contains the fix.

Step 6 — Tag the release

For example:

git tag v2.0.1
git push origin v2.0.1

The history might look like:

v2.0
 |
 +---- bug discovered
 |
 +---- hotfix
 |
v2.0.1

Step 7 — Deploy

The CI/CD pipeline deploys the corrected version:

hotfix
   ↓
PR
   ↓
main
   ↓
v2.0.1
   ↓
Build
   ↓
Tests
   ↓
Deploy
   ↓
Production

Step 8 — Bring the fix back into ongoing development

This is a very important interview point.

Imagine:

main    → v2.0.1
develop → future v3.0

If the hotfix exists only in main, future v3.0 development could miss the fix.

Therefore, in GitFlow the hotfix changes also need to reach develop.

Conceptually:

               hotfix/2.0.1
              /            \
             v              v
           main          develop
             |
          v2.0.1

This keeps both production and future development synchronized.

Hotfix Using GitHub Flow

GitHub Flow doesn't require a special GitFlow-style hotfix branch type.

Create a short-lived fix branch from the production branch, commonly main:

git switch main
git pull origin main

git switch -c fix/payment-error

Fix and push:

git add .
git commit -m "Fix payment processing error"

git push -u origin fix/payment-error

Then:

main
 |
 +---- fix/payment-error
            |
            PR
            |
      Review + CI
            |
            v
          main
            |
          Deploy

The branch name could also be:

hotfix/payment-error

The exact naming convention is a team decision.

Hotfix in Trunk-Based Development

In trunk-based development, the fix should normally be small and integrated quickly.

For example:

main
 |
 +-- normal changes
 |
 +-- production bug discovered
 |
 +-- small fix
 |
 +-- CI
 |
 +-- deploy

If branches are required:

git switch main
git pull origin main

git switch -c fix/payment-error

Then quickly:

fix
 ↓
Test
 ↓
PR
 ↓
CI
 ↓
main
 ↓
Deploy

The branch should remain very short-lived.

Important Production Scenario

Suppose main contains code that has not yet been deployed, while production is still running tag v2.0.

Then blindly creating the hotfix from the latest main could include unrelated unreleased changes.

The team should identify the exact production revision/tag and follow its release-branching policy.