Hotfix Workflow

The Hook (The "Byte-Sized" Intro)

Production is down. Users are seeing errors. You need a fix deployed in 30 minutes, not 3 days. The hotfix workflow is your emergency procedure: branch from production, fix, test, deploy, then merge back to main. No skipped steps, no "we'll clean it up later." Speed AND safety.

📖 What is the Hotfix Workflow?

A streamlined process for creating, testing, and deploying emergency fixes to production with minimal delay while maintaining code quality.

Conceptual Clarity

Hotfix workflow steps:

Step	Action	Time Target
1. Branch	Create from production tag/branch	1 minute
2. Fix	Minimal, targeted change	5-30 minutes
3. Test	Run critical tests locally + staging	5-10 minutes
4. Review	Fast-track review (1 reviewer)	5-15 minutes
5. Deploy	Tag, merge, deploy to production	5-10 minutes
6. Merge back	Merge hotfix back into `main`	5 minutes

Hotfix vs regular fix:

Aspect	Regular Fix	Hotfix
Branch from	`main`	Production tag
Review	1-2 reviewers, 24h SLA	1 reviewer, 1h SLA
Testing	Full suite	Critical paths only
Scope	Any size	Minimal change
Merge	Squash to main	To production + back to main

Real-Life Analogy

A hotfix is like emergency surgery. You don't schedule it for next week. You assemble the team, make the minimal necessary fix, stabilize the patient, and then do the full checkup later.

Visual Architecture

gitGraph commit id: "v1.0.0" branch hotfix/payment-crash commit id: "fix: null check" checkout main merge hotfix/payment-crash id: "v1.0.1" tag: "v1.0.1" commit id: "continue dev"

Why It Matters

Speed: Gets fixes to users in minutes, not days.
Safety: Despite urgency, still reviewed and tested.
Traceability: Tagged and documented for post-mortems.
Merge back: Ensures main isn't missing the fix.

Code

bash

# ─── 1. Branch from production ───
git fetch --tags
git checkout -b hotfix/PROD-501-payment-crash v1.0.0

# ─── 2. Make the minimal fix ───
# Edit the file, commit
git add src/payments/process.js
git commit -m "fix(payments): add null check for expired cards

Fixes PROD-501. Expired card object was null, causing TypeError."

# ─── 3. Test ───
npm test -- --grep "payments"

# ─── 4. Push + fast-track PR ───
git push -u origin hotfix/PROD-501-payment-crash
gh pr create --title "HOTFIX: payment crash on expired cards" \
  --body "Production fix for PROD-501" --label "hotfix"

# ─── 5. After approval: tag and deploy ───
git tag v1.0.1
git push origin v1.0.1

# ─── 6. Merge back to main ───
git checkout main
git merge hotfix/PROD-501-payment-crash
git push origin main

# ─── 7. Clean up ───
git branch -d hotfix/PROD-501-payment-crash
git push origin :hotfix/PROD-501-payment-crash

Key Takeaways

Branch from the production tag, not main (which may have unreleased work).
Make the smallest possible fix — no refactoring during emergencies.
Fast-track review (1 reviewer, < 1 hour) but don't skip review.
Always merge back to main — don't let main diverge from production.

Interview Prep

Q: Why do you branch from the production tag, not main? A: main may contain unreleased features that haven't been tested for production. Branching from the production tag ensures the hotfix applies cleanly to what's actually deployed.
Q: What is the most important rule during a hotfix? A: Keep the fix minimal. Only fix the immediate problem. Refactoring, improvements, or "while I'm here" changes should go in a separate, normal PR later.
Q: What happens if you forget to merge the hotfix back to main? A: main diverges from production — the fix exists in production but not in main. Future releases from main may reintroduce the bug.