Git Hotfix in Production: The GitHub Flow Emergency Playbook

It's Friday 5pm. Your Slack lights up: "Production checkout is broken. Users can't complete orders." Your feature branch is halfway done. Your stomach drops. What do you do?

The answer with GitHub Flow is simpler than you think, and there's one rule that matters above all others.

The One Rule: Always Branch from main

Do NOT branch from your feature branch. main is what's running in production. Your feature branch may have unreviewed code that was never deployed. Branching from it would silently ship that code alongside your hotfix.

The Hotfix Playbook (Step by Step)

Step 1: Leave your feature branch, switch to main

git checkout main
git pull origin main

Step 2: Create a hotfix branch from main

git checkout -b fix/DEV-911-null-crash-on-checkout

Step 3: Make the minimal fix. ONLY the fix.

Resist the urge to refactor "while you're there." Every extra line is a risk at 5pm Friday. If you notice something else broken, file a separate ticket and fix it later.

git add src/checkout/CartSummary.tsx
git commit -m "fix(checkout): prevent null crash when cart is empty"

Step 4: Open a PR, label it as a hotfix and request urgent review

## What
Fix null crash on checkout when cart is empty.

## Why
🚨 HOTFIX, production is down. Ticket: DEV-911
Users hitting /checkout with an empty cart get a 500 error.

## How to Test
1. Add item to cart → checkout → works ✅
2. Go directly to /checkout with empty cart → redirect, no crash ✅

## Risk
Low, single null-check added, no logic changes.

Step 5: Merge to main and deploy

git checkout main
git pull origin main
git merge fix/DEV-911-null-crash-on-checkout
git push origin main
# Trigger your CI/CD deploy (Vercel, GitHub Actions, etc.)

Step 6: Pull the fix into your feature branch so you don't conflict later

git checkout feat/DEV-42-user-login
git merge main
# Resolve any conflicts, then continue your feature work

Acceptance Criteria

A hotfix is done correctly when:

☐ Hotfix branch was created from main, not from a feature branch

☐ PR diff contains only the fix, no unrelated changes

☐ Automated tests pass before merge

☐ At least one team member reviewed and approved

☐ Deployed and verified in production within team SLA

☐ All active feature branches updated from main after the hotfix merges

Common Mistakes

❌ Branching from your half-done feature branch, you ship unreviewed code to production.

❌ "While I'm here" changes, scope creep under pressure causes more bugs than it fixes.

❌ Skipping review because it's urgent, a second pair of eyes catches mistakes you're too stressed to see.

TL;DR

Branch from main. Fix only what's broken. Review. Deploy. Update everyone's branches. The pressure is real. The process keeps you from making it worse.