Git
Intermediate 14 min read Git

Git Workflows (GitFlow, Trunk-based)

Branching models standardize how a team integrates work. GitFlow uses main, develop and release/hotfix branches for scheduled releases; GitHub Flow keeps everything on short-lived branches off main; trunk-based development commits small changes to main constantly with strong CI and feature flags.

GitFlowtrunk-basedGitHub Flowdeveloprelease branchhotfixfeature flags
Prerequisites: Branching & Merging
Introduction

What is this?

Git workflows define which branches exist and how work flows between them. GitFlow maintains parallel main (production) and develop branches with feature, release and hotfix branches. GitHub Flow works from a single main branch with short feature branches merged via pull requests. Trunk-based development treats main as the trunk that everyone integrates into, often multiple times a day.

Motivation

Why do you need it?

  • A defined workflow makes every merge predictable and releases reproducible.
  • It encodes process: where features, releases and hotfixes enter the codebase.
  • It balances stability (protection of main) against velocity (how fast work ships).
  • It plugs directly into CI/CD gates such as required checks and deployment triggers.
Think about it

Mental model

Imagine

Traffic rules on a highway

Think of

A git workflow

Rules keep traffic flowing at the speed the team chooses. No rules means chaos; too many rules means gridlock. GitFlow is the slow lane, trunk-based the express lane.

Mechanics

How it works

  • GitFlow: features branch from and merge into develop; release branches cut from develop, stabilized, and merged to both main and develop; hotfixes branch from main and merge back to both.
  • GitHub Flow: every change starts as a short-lived branch off main; a pull request reviews it; merging to main triggers a deploy.
  • Trunk-based: developers integrate to main constantly, using small commits and feature flags instead of long-lived branches.
  • Releases in trunk-based can be branch or tag cuts from main when you ship.
  • All workflows rely on branch protection and CI checks to keep main green.

Branches in the GitFlow model.

main
develop
feature/*
release/*
hotfix/*
Merges back
Reference

Key commands

git switch -c feature/login

Start a feature branch off the current base.

git merge --no-ff develop

Force a merge commit so feature work stays visible in history.

git tag -a v1.0.0 -m 'Release 1.0.0'

Tag a release commit for traceability.

git switch -c hotfix/1.0.1 main

Cut a hotfix branch from main in GitFlow.

git push origin --delete feature/login

Delete a remote branch after it is merged.

Hands-on

Examples

GitHub Flow in five commands

GitHub Flow in five commands
git switch -c feature/login
# ... implement and commit ...
git push -u origin feature/login
# Open a pull request on GitHub → review → merge to main
git switch main
git pull
git branch -d feature/login

A short-lived feature branch is pushed and merged through a reviewed pull request, main is updated, and the branch is deleted. This is the entire GitHub Flow loop, repeated many times a day.

Real world

In production

  • GitFlow suits products with scheduled releases and a stable, supportable main.
  • Trunk-based development fits continuous delivery teams deploying many times a day.
  • GitHub Flow works well for product teams deploying continuously with short-lived PRs.
  • Release branches (or tags) freeze a version for stabilization and backporting.
Guidelines

Best practices

  • Match the workflow to your release cadence — do not adopt GitFlow ceremony for daily deploys.
  • Protect main with required pull request review and passing CI before merge.
  • Keep feature branches short; long-lived branches are the enemy of every workflow.
  • In trunk-based work, rely on feature flags and strong automated tests, not long-lived branches.
  • Document the chosen workflow in CONTRIBUTING.md so everyone follows the same rules.
Watch out

Common mistakes

  • Adopting GitFlow for a team that deploys continuously, adding pointless release ceremony.
  • Letting release branches drift far from main and develop, causing painful merges.
  • Committing directly to main without CI or review in trunk-based setups.
  • Running mixed workflows in one repo so nobody knows where a branch belongs.
Root cause analysis

Common issues

Error
Massive conflicts merging a release branch
Root cause

Release branch drifted from develop/main for weeks.

Fix

Merge or rebase develop into the release branch regularly during stabilization.

Error
Hotfix merged to main but lost on develop
Root cause

GitFlow requires merging hotfixes into both branches and only one was done.

Fix

Merge or cherry-pick the hotfix commit into develop as well.

Error
Deploy fired for a feature commit meant for a later release
Root cause

The deploy trigger is 'push to main' with no release gating.

Fix

Gate deploys on tags or a release branch instead of raw main pushes.

When things break

Debugging tips

  • git log --oneline --graph to audit whether merges follow the intended structure.
  • git branch -a to see local and remote branches and spot strays.
  • Check CONTRIBUTING.md for the repository's expected branch flow.
  • git reflog to recover when a release or hotfix merge went wrong.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/3
1

In GitFlow, which branch holds production-ready code?

2

Trunk-based development encourages long-lived feature branches.

3

In GitFlow, a hotfix branch should be cut from which branch?

Quick reference

Cheat sheet

Workflow patterns
git switch -c feature/xGitFlow/GitHub Flow feature start
git switch -c release/1.0.0 developCut a release from develop
git switch -c hotfix/1.0.1 mainCut a hotfix from main
git merge --no-ff developVisible merge commit
git tag -a v1.0.0 -m 'msg'Tag a release
git push origin --delete branchDelete remote branch
Go deeper

Official documentation

Distributed Git — Distributed Workflows
docs
GitHub Flow guide
docs
GitFlow — a successful branching model
docs
Trunk Based Development
docs