Handling a Production Hotfix

1. What is a Production Hotfix?

A production hotfix is an urgent code change made to fix a critical problem in the application currently running in production.

Typical examples include:

• Login is failing for users.
• Payment processing is broken.
• A critical API is returning 500 errors.
• A serious security vulnerability needs immediate remediation.
• An important production feature stopped working.

The key principle is:

Start the hotfix from the exact production code, fix only the necessary issue, test it, deploy it, and make sure the fix is brought back into ongoing development.

2. Simple Git Example

Assume:

Production version : v2.0.0
Production branch  : main
Development branch : develop

Create a hotfix from main:

git switch main
git pull origin main

git switch -c hotfix/2.0.1

Fix the issue and commit:

git add .
git commit -m "Fix production login issue"

Push the branch:

git push -u origin hotfix/2.0.1

Then create a Pull Request:

hotfix/2.0.1
      |
      | PR + Review + CI
      v
     main

After deployment, if using GitFlow, ensure the fix also reaches develop.

3. Complete Production Hotfix Flow

Suppose production is currently:

main
 |
 A---B---C
         |
       v2.0.0

Meanwhile, developers are working on the next version:

main
A---B---C
         \
          D---E---F   develop

A critical bug is discovered in v2.0.0.

You should not create the hotfix from develop, because develop may contain unfinished features.

Instead:

main
A---B---C
         \
          H   hotfix/2.0.1

Step 1: Confirm the Production Version

First determine exactly what code is running in production.

For example:

Production → v2.0.0

Ideally, production releases are tagged:

git tag

You might see:

v1.0.0
v1.1.0
v2.0.0

This is important because the hotfix should be based on the production baseline, not unrelated development code.

Step 2: Create the Hotfix Branch

If main represents the current production version:

git switch main
git pull origin main

git switch -c hotfix/2.0.1

Now:

                  hotfix/2.0.1
                 /
A---B---C
        main

Step 3: Make the Minimum Necessary Change

Suppose production login fails because of a null-reference issue.

Fix only that problem.

For example:

if (user == null)
{
    return Unauthorized();
}

Then:

git add .
git commit -m "Fix null reference in production login"

A hotfix should generally be small and focused.

Avoid mixing unrelated changes such as:

Hotfix login bug
+ Refactor authentication
+ Upgrade packages
+ Change UI
+ Rename classes

That increases deployment risk.

Prefer:

Hotfix login bug
        ↓
Small targeted change

4. Push and Create a Pull Request

Push the branch:

git push -u origin hotfix/2.0.1

Create:

hotfix/2.0.1
      |
      | Pull Request
      v
     main

Even though the fix is urgent, the normal quality controls should be retained as much as the incident allows:

Hotfix PR
   |
   +--> Code Review
   |
   +--> Build
   |
   +--> Unit Tests
   |
   +--> Relevant Integration/Security Checks
   |
   v
Merge

Urgent should not automatically mean:

git push directly to main

5. Test the Hotfix

Before production deployment, verify the specific issue and relevant regression areas.

For example:

Hotfix
  ↓
Build
  ↓
Unit Tests
  ↓
Targeted Regression Testing
  ↓
Staging/UAT validation if feasible
  ↓
Production

For a login issue, test at least the affected scenarios:

Valid login       ✓
Invalid login     ✓
Locked user       ✓
Null/missing user ✓
JWT generation    ✓

The exact validation process depends on the severity of the incident and the organization's emergency-change procedure.

6. Merge the Hotfix into main

After approval:

hotfix/2.0.1
       |
       v
      main

For example:

A---B---C---H
            |
           main

H contains the production fix.

7. Tag the New Production Version

If the team uses version tags, create the new version:

git switch main
git pull origin main

git tag -a v2.0.1 -m "Production hotfix v2.0.1"
git push origin v2.0.1

Now:

A---B---C---H
        |   |
      v2.0.0
            |
          v2.0.1

This makes it easy to identify which commit corresponds to each production release.

8. Deploy the Hotfix

The CI/CD pipeline can deploy the corrected version:

v2.0.1 / main
      |
      v
CI Pipeline
      |
      +--> Build
      +--> Tests
      +--> Package
      |
      v
CD Pipeline
      |
      v
Production

After deployment, verify:

• Application health
• Logs
• Error rates
• The original production issue
• Relevant business functionality

A rollback mechanism should also be available in case the hotfix causes another critical problem.

9. Bring the Fix Back into Development

This is especially important with GitFlow.

Suppose:

main
A---B---C---H
        \
         D---E---F   develop

H fixed production, but develop does not yet contain the fix.

If you forget this step, the next release could reintroduce the same bug.

Therefore, integrate the hotfix into develop as well, normally through the team's PR process:

hotfix/2.0.1
      |
      +------> main
      |
      +------> develop

Result conceptually:

               D---E---F---H'
              /
A---B---C----+---------H
                       |
                      main

The exact commit graph depends on the merge strategy.

10. Complete Hotfix Workflow

Critical Production Bug
          |
          v
Identify production version
          |
          v
Create hotfix branch
from production baseline
          |
          v
hotfix/2.0.1
          |
          v
Implement minimal fix
          |
          v
Commit + Push
          |
          v
Pull Request
          |
          +--> Review
          +--> Build
          +--> Tests
          |
          v
Merge into main
          |
          v
Tag v2.0.1
          |
          v
Deploy Production
          |
          v
Verify / Monitor
          |
          v
Propagate fix to develop
(if using GitFlow)

11. Hotfix in Different Branching Strategies

GitFlow

GitFlow has an explicit hotfix/* concept:

main
 |
 +--> hotfix/2.0.1
          |
          +----> main
          |
          +----> develop

GitHub Flow

Usually create a short-lived fix branch from main:

main
 |
 +--> fix/production-login
          |
          v
          PR
          |
          v
         main

There may be no develop branch to update.

Trunk-Based Development

Create a very small fix from the production/trunk baseline and integrate it quickly:

main/trunk
    |
    +--> short-lived fix
              |
              v
             main

The exact release procedure depends on whether production is deployed directly from trunk or from tagged/release commits.

12. Important Caution: What If main Is Ahead of Production?

This is an important real-world scenario.

Do not automatically assume:

main = production

Some organizations may have:

main → newer code
Production → v2.0.0

In that case, creating the hotfix from the latest main could accidentally include unreleased changes.

Instead, branch from the actual production release/tag according to the team's release process, for example:

git switch -c hotfix/2.0.1 v2.0.0

This gives:

v2.0.0
   |
   +---- hotfix/2.0.1

This is why knowing the exact production commit/version is critical.

13. Key Points

• A hotfix is an urgent production fix.
• Identify the exact production version before starting.
• Create the hotfix from the production baseline, not from unfinished development.
• Common naming:

hotfix/2.0.1
fix/production-login

• Keep the change small and focused.
• Prefer a Pull Request, review, and CI checks even for urgent fixes.
• Test the fix and relevant regression scenarios.
• Merge the corrected code into the production branch.
• Tag releases when your release process uses version tags.
• Deploy through the controlled CI/CD process.
• Verify and monitor after deployment.
• With GitFlow, propagate the hotfix back into develop.
• If main is ahead of production, branch from the appropriate production tag/commit instead.
• Have a rollback strategy for production deployments.

14. Interview Answer

When handling a production hotfix, I first identify the exact version or commit currently running in production. I create a short-lived hotfix branch from that production baseline, make the minimum necessary change, commit it, and push the branch. I then create a Pull Request and run the required code review, build, tests, and relevant validation. Once approved, I merge the fix into the production branch, tag the new version if our release process uses tags, and deploy it through the CI/CD pipeline. After deployment, I verify and monitor production. If we use GitFlow, I also merge or propagate the hotfix into develop so the same bug is not reintroduced in a future release.