← Back to Articles         
Handling an Urgent Production Hotfix While Working on a Feature

Handling an Urgent Production Hotfix While Working on a Feature

Published on 03 Oct 2026     7 min read Git & GitHub
Scenario Based Questions

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 worktree is 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, usually main, pull the latest changes, and create a dedicated hotfix branch such as hotfix/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.

← Back to Articles