GitFlow, GitHub Flow, and Trunk-Based Development

These are Git branching strategies that define how developers create branches, integrate changes, and release software.

The major difference is how much branching they use and how frequently code is integrated into the main branch.

1. What is Trunk-Based Development?

What is it?

Trunk-based development (TBD) is a branching strategy where developers integrate their changes frequently into a single primary branch called the trunk, usually:

main

Developers either commit through tightly controlled workflows or, very commonly, use very short-lived feature branches that are merged back into main quickly.

The key idea is:

Keep branches short-lived and integrate changes into main frequently.

Typical flow:

main
 |
 +--> short feature branch
 |          |
 |          +--> main
 |
 +--> short feature branch
 |          |
 |          +--> main

Simple Example

Start from the latest main:

git switch main
git pull origin main

Create a short-lived branch:

git switch -c feature/login-validation

Make a small change:

git add .
git commit -m "Add login validation"

Push:

git push -u origin feature/login-validation

Create a Pull Request:

feature/login-validation
          |
          | PR
          v
         main

After review and CI checks, merge it quickly.

2. How Trunk-Based Development Works

Suppose three developers are working:

Developer A → Login validation
Developer B → Payment fix
Developer C → Logging improvement

They create small, short-lived branches:

feature/login
fix/payment
feature/logging

and integrate frequently:

A---B---C---D---E---F---G   main
     \ /
      X       short-lived branch

             \ /
              Y             short-lived branch

The important point is that developers do not keep feature branches separate for weeks or months.

Why?

Long-lived branches can diverge significantly:

main
A---B---C---D---E---F
     \
      G---H---I---J---K   long-lived feature

When finally merged, there may be many conflicts.

Trunk-based development tries to keep the distance small:

main
A---B---C---D---E
     \ /
      X
         \ /
          Y

Frequent integration generally makes integration problems smaller and earlier.

3. What About Incomplete Features?

This is an important practical question.

If developers frequently merge into main, how can unfinished functionality be prevented from affecting users?

One common technique is a feature flag.

For example:

if (featureFlags.NewCheckoutEnabled)
{
    ShowNewCheckout();
}
else
{
    ShowExistingCheckout();
}

The code may exist in main, but the functionality remains disabled until it is ready.

Conceptually:

Code merged into main
        |
        v
Feature flag OFF
        |
        v
Users don't see feature

Later:

Feature tested and ready
        |
        v
Feature flag ON
        |
        v
Users see feature

This separates:

Code deployment

from:

Feature release

4. Advantages of Trunk-Based Development

• Frequent integration.
• Smaller changes.
• Fewer problems caused by long-lived branches.
• Works well with strong CI/CD practices.
• Encourages automated testing.
• Supports frequent releases.
• Keeps developers close to the latest main.

Disadvantages / Challenges

It requires discipline.

Teams generally need:

• Reliable automated tests
• Fast CI pipelines
• Good code reviews
• Small changes
• Strong main branch protection
• Feature flags when appropriate

If broken code is frequently merged into main, trunk-based development becomes difficult.

5. What is GitHub Flow?

What is it?

GitHub Flow is a simple branch-based workflow centered around one primary branch, usually:

main

Developers create a branch from main, make changes, open a Pull Request, review/test the changes, and merge them back into main.

The basic workflow is:

main
 |
 v
Create Branch
 |
 v
Make Changes
 |
 v
Push Branch
 |
 v
Pull Request
 |
 v
Code Review + CI
 |
 v
Merge into main
 |
 v
Deploy

Unlike GitFlow, GitHub Flow normally does not require a permanent develop branch or dedicated release/* branches.

6. GitHub Flow Example

Suppose you need to develop login functionality.

Start with:

git switch main
git pull origin main

Create a branch:

git switch -c feature/login

Develop:

git add .
git commit -m "Add login feature"

Push:

git push -u origin feature/login

Now create a Pull Request:

feature/login
     |
     | Pull Request
     v
    main

The PR goes through:

Pull Request
     |
     +--> Code Review
     |
     +--> Build
     |
     +--> Unit Tests
     |
     +--> Other Checks
     |
     v
   Approved
     |
     v
Merge into main

After merging, the branch can be deleted.

7. GitHub Flow Complete Workflow

A simple example:

main
 |
 A---B-------------------M
      \                 /
       C---D---E---------
        feature/login

Where:

A, B     → Existing main commits
C, D, E  → Feature work
M        → Integration into main

Depending on the selected merge strategy, the PR may use:

• Merge commit
• Squash merge
• Rebase merge

8. Why Use GitHub Flow?

GitHub Flow is simpler than GitFlow.

Instead of:

main
develop
feature/*
release/*
hotfix/*

the normal structure is closer to:

main
 |
 +--> feature/login
 |
 +--> feature/payment
 |
 +--> fix/order-error

Everything ultimately returns to main through a Pull Request.

Advantages

• Simple to understand.
• Fewer long-lived branches.
• Works well with Pull Requests.
• Good fit for CI/CD.
• Supports frequent releases.
• Less branch-management overhead than GitFlow.

Potential Challenges

• main needs to remain in a releasable state.
• Strong CI/testing is important.
• Large features may need feature flags or careful decomposition.
• Teams with complicated scheduled release/version maintenance may need additional release processes.

9. GitFlow vs GitHub Flow vs Trunk-Based Development

High-Level Comparison

10. GitFlow Flow

GitFlow:

feature/*
    |
    v
 develop
    |
    v
release/*
    |
    +------> main
    |
    +------> develop

Production problem:

main
 |
 v
hotfix/*
 |
 +------> main
 |
 +------> develop

It has more branch types and explicit release management.

11. GitHub Flow

GitHub Flow is simpler:

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

Essentially:

main
  ↓
branch
  ↓
commit
  ↓
push
  ↓
PR
  ↓
review + CI
  ↓
merge
  ↓
main

12. Trunk-Based Development

Trunk-based development emphasizes very frequent integration:

main
A---B---C---D---E---F---G
     \ /
      X
             \ /
              Y

Developers keep their work close to main.

Think of it as:

Small Change
     ↓
Short-Lived Branch
     ↓
Review + CI
     ↓
main
     ↓
Repeat Frequently

13. GitHub Flow vs Trunk-Based Development

These two can look very similar in practice.

For example, both may use:

main
 |
 +--> short-lived feature branch
          |
          v
          PR
          |
          v
         main

The difference is mainly in emphasis and discipline.

GitHub Flow

Emphasizes the branch + Pull Request workflow:

Branch
  ↓
Changes
  ↓
PR
  ↓
Review
  ↓
Merge

Trunk-Based Development

Emphasizes:

Very small changes
        +
Very short-lived branches
        +
Very frequent integration
        ↓
       main

So a team can use GitHub Pull Requests while practicing trunk-based development.

They are not necessarily mutually exclusive concepts.

14. Practical Scenario

Suppose your team is developing an ASP.NET Core application.

GitFlow

You might have:

main
develop
feature/jwt-authentication
feature/payment
release/2.0
hotfix/2.0.1

This gives explicit control over releases.

GitHub Flow

You might have:

main
 |
 +--> feature/jwt-authentication
 |
 +--> feature/payment
 |
 +--> fix/login-error

Each branch goes through a PR directly into main.

Trunk-Based

You might break JWT development into smaller changes:

main
 |
 +--> add-token-service
 |
 +--> add-token-validation
 |
 +--> add-auth-middleware

Each small change is merged quickly.

An incomplete feature might remain disabled using:

Feature Flag = OFF

until it is ready.

15. Key Points

GitFlow

Remember:

main
develop
feature/*
release/*
hotfix/*

Best understood as a structured release-oriented branching model.

GitHub Flow

Remember:

main
 ↓
branch
 ↓
PR
 ↓
review + CI
 ↓
main

It is simpler and centered around Pull Requests.

Trunk-Based Development

Remember:

Small changes
     ↓
Short-lived branches
     ↓
Frequent integration
     ↓
main

The goal is to avoid long-lived divergent branches.

Feature flags are often used for incomplete functionality.

Easy Interview Memory

GitFlow
   ↓
More branches + structured releases

GitHub Flow
   ↓
main + feature branch + PR

Trunk-Based
   ↓
main + very small/frequent integrations

The exact implementation varies by organization; these are workflow models rather than rigid Git requirements.

16. Interview Answer

GitFlow, GitHub Flow, and trunk-based development are branching strategies. GitFlow uses main, develop, feature, release, and hotfix branches, making it suitable for teams that need a structured release process. GitHub Flow is simpler: developers create a branch from main, make changes, create a Pull Request, complete review and CI checks, and merge back into main. Trunk-based development focuses on integrating very small changes into main frequently, usually through very short-lived branches, and often uses feature flags for incomplete functionality. The main difference is that GitFlow has more branch types and release structure, while GitHub Flow and trunk-based development favor simpler branching and more frequent integration.