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?
With GitHub Flow the answer is simpler than you think, and one rule 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 mainStep 2: create a hotfix branch from main
git checkout -b fix/DEV-911-null-crash-on-checkoutStep 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 workAcceptance 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.
Recommended for you
- CollaborationHerdr
When Phone Approval of Coding Agents Earns Its Complexity
Approving agent decisions from your phone sounds nice but is usually the wrong answer. It pays off in exactly one scenario: long runs that block while you are away.
- CollaborationHerdrClaude Code
How I Stopped Losing Track of Which Agent Owns Which Task
Three agents in one workspace is where you stop knowing which agent owns which PR. One task, one branch, one worktree, one agent fixes it.
- CollaborationClaude CodeAmp
Why I Stopped Running Parallel Agents in the Same Repo
Agents sharing one workspace collide on branches, state, and review diffs. Sibling worktrees with a fresh base branch fix all three. Here is the setup.
- CollaborationHerdrClaude Code
When to Map One Agent to One Worktree to One Branch
Sharing a workspace across agents feels efficient but is the most expensive shortcut in a multi-agent workflow. Here is when one-to-one mapping earns its overhead.
Enjoyed this article?
Subscribe for new articles. No spam. Unsubscribe anytime.