Handling an Urgent Production Hotfix While Working on a Feature
1. What is it?
A hotfix is an urgent code change made to fix a critical problem in the Production environment.
For example:
- Production login is failing.
- Payment processing has stopped.
- An important API is returning
500. - A critical security issue needs an immediate fix.
If I am currently working on feature/login, I should not mix my unfinished feature changes with the Production fix.
A typical approach is:
Save unfinished feature work
↓
Switch to latest Production/main branch
↓
Create a hotfix branch
↓
Fix + test
↓
PR / review / CI
↓
Deploy to Production
↓
Bring hotfix into other active branches
↓
Resume feature work
2. Simple Syntax / Sample
Suppose I am working on:
feature/login
and have uncommitted changes.
Step 1 — Save my current work
I can commit it if it is in a suitable state:
git add .
git commit -m "WIP: login feature"
Or, for temporary unfinished changes, I can stash them:
git stash push -m "WIP login feature"
Step 2 — Get the latest Production branch
Assuming main represents the Production code:
git switch main
git pull origin main
Step 3 — Create the hotfix branch
git switch -c hotfix/login-production-error
Step 4 — Fix and commit
git add .
git commit -m "Fix production login error"
Step 5 — Push
git push -u origin hotfix/login-production-error
Then create a Pull Request to main, complete review/CI, merge it, and deploy according to the team's Production process.
3. Detailed Explanation
Assume I am currently developing:
main
\
feature/login
↑
Working here
Suddenly, a critical Production issue is reported.
I don't want my unfinished login feature going to Production.
Step 1 — Preserve the Current Feature Work
First:
git status
If my work is unfinished, I can stash it:
git stash push -m "WIP login feature"
The working directory becomes clean.
Alternatively, if the work is appropriate to commit:
git add .
git commit -m "WIP: login feature"
In a real team, I would generally keep such a WIP commit on my feature branch rather than merge it anywhere.
Step 2 — Start from the Correct Production Baseline
Switch to main:
git switch main
Get the latest code:
git pull origin main
This is important.
I don't want to create the hotfix from an outdated local main.
Now:
A --- B --- C main
\
D feature/login
Create the hotfix from C:
git switch -c hotfix/login-production-error
Result:
A --- B --- C main
|\
| \--- D feature/login
\
hotfix/login-production-error
Step 3 — Implement the Smallest Safe Fix
Make only the changes required to resolve the Production issue.
For example:
if (user == null)
{
return Unauthorized();
}
Then:
git add .
git commit -m "Fix production login error"
Now:
A --- B --- C
|\
| \--- D feature/login
\
H hotfix
H is the hotfix commit.
A hotfix should generally be focused and minimal. An urgent Production incident is usually not the right time to include unrelated refactoring or feature changes.
Step 4 — Test the Hotfix
Before Production deployment, run the appropriate tests.
For example:
dotnet build
dotnet test
Depending on the team's process, the hotfix may also go through:
Developer testing
↓
Pull Request
↓
Code review
↓
CI build
↓
Automated tests
↓
Required approvals
↓
Merge
↓
Production deployment
Urgent does not mean bypassing important safety controls unless the organization's incident procedure explicitly defines an emergency process.
Step 5 — Push and Create a Pull Request
Push the branch:
git push -u origin hotfix/login-production-error
Then create:
hotfix/login-production-error
↓
Pull Request
↓
main
After approval:
A --- B --- C --- H
↑
main
Then the CI/CD pipeline can deploy the corrected version to Production.
4. Bring the Hotfix into Other Active Branches
This is an important interview point.
Suppose development is also happening on another long-lived branch such as develop.
If the Production fix exists only in main, a future release could accidentally reintroduce the original bug.
Therefore, the hotfix should also be incorporated into the relevant active development line.
For example:
git switch develop
git pull origin develop
git merge main
git push origin develop
Or the team may merge the hotfix branch into both main and develop, depending on its branching strategy.
Conceptually:
H -------- main
/
A --- B --- C
\
D --- E -------- develop
\
incorporate H
The exact process depends on whether the team uses GitFlow, GitHub Flow, trunk-based development, release branches, or another strategy.
5. Resume the Feature Work
Once the Production issue is handled:
git switch feature/login
If I used stash:
git stash list
Then:
git stash pop
My unfinished feature work returns.
I would also bring the hotfix/latest main into my feature branch when appropriate:
git fetch origin
git merge origin/main
or, if the team's workflow prefers rebase:
git rebase origin/main
Now my feature development includes the Production correction.
6. What If I Don't Want to Stash My Current Work?
Another useful option is git worktree.
It allows me to have another working directory for the hotfix without disturbing my current feature working tree.
For example:
git fetch origin
git worktree add -b hotfix/login-production-error ../production-hotfix origin/main
Now I can have:
Folder 1
project/
↓
feature/login
Folder 2
production-hotfix/
↓
hotfix/login-production-error
This can be convenient when switching contexts during urgent incidents.
For a basic interview answer, however, stash → hotfix branch → fix → PR → resume is usually easier to explain.
7. Hotfix Workflow
Currently working
feature/login
│
▼
Save unfinished work
(commit or stash)
│
▼
Switch to main
│
▼
Pull latest main
│
▼
Create
hotfix/production-issue
│
▼
Implement minimal fix
│
▼
Build + Test
│
▼
Push hotfix
│
▼
Pull Request
│
▼
Review + CI checks
│
▼
Merge to main
│
▼
Deploy Production
│
▼
Propagate fix to
relevant active branches
│
▼
Return to feature/login
│
▼
Restore/update feature work
8. Key Points
- Never mix unfinished feature code with an urgent Production hotfix.
- First preserve your current work using a commit or:
git stash
- Create the hotfix from the current Production baseline, often the latest
main:
git switch main
git pull origin main
git switch -c hotfix/production-issue
- Keep the Production fix small and focused.
- Build and test it.
- Push the hotfix and normally use a Pull Request.
- Follow required code-review, CI/CD, and Production approval procedures.
- After deployment, ensure the hotfix reaches other relevant development/release branches so the bug is not reintroduced.
- Return to your feature branch and restore your work:
git switch feature/login
git stash pop
git worktreeis another useful option when you need to work on the hotfix without disturbing the current working tree.
9. Interview Answer
If an urgent Production issue occurs while I'm working on a feature, I would first preserve my unfinished feature work using a commit or
git stash. Then I would switch to the latest Production baseline, usuallymain, pull the latest changes, and create a dedicated hotfix branch such ashotfix/login-production-error. I would implement the smallest safe fix, build and test it, push the branch, and raise a Pull Request so the required review and CI checks can run before Production deployment. After the hotfix is released, I would make sure the fix is incorporated into any relevant active development or release branches. Finally, I would return to my feature branch, restore my unfinished work, and continue development.