Introduction

If a hotfix branch contains a fix that your feature branch also needs, the normal solution is to merge the hotfix branch into the feature branch. That keeps the feature branch up to date with the bug fix while preserving the hotfix history. In most cases, the workflow is simple: fetch, check out the feature branch, merge the hotfix branch, resolve conflicts if needed, and test.

Merge the Hotfix into the Feature Branch

Start by updating your local refs:

git fetch origin

Then switch to the feature branch that should receive the fix:

git switch feature-branch

Now merge the hotfix branch into it:

git merge hotfix-branch

If both branches exist locally, that is enough. If the hotfix only exists on the remote, merge from the remote-tracking ref instead:

git merge origin/hotfix-branch

A Complete Example Flow

A typical sequence looks like this:

git fetch origin
git switch feature-branch
git merge origin/hotfix-branch

If the merge succeeds cleanly, run your tests and then push the updated feature branch:

git push origin feature-branch

That preserves the hotfix commit history and makes the fix part of the feature branch going forward.

What If There Are Merge Conflicts?

If both branches touched the same lines, Git may stop for conflict resolution. In that case:

1. open the conflicted files
2. resolve the conflict markers
3. stage the resolved files
4. complete the merge commit

Example:

git status
git add path/to/resolved-file
git commit

The important part is to resolve the code logically, not just mechanically. The hotfix may need to be adapted to the work already in progress on the feature branch.

When Cherry-Pick Might Be Better

If the hotfix branch contains several commits and you only need one of them, git cherry-pick may be a better tool than merging the whole branch. But if the feature branch should inherit the actual hotfix branch history, merge is the more honest operation.

So the rule of thumb is:

• merge when you want the branch history and all relevant changes
• cherry-pick when you only want selected commits

That distinction keeps the Git history easier to understand later.

Why Merge into the Feature Branch at All?

This is a common workflow when a bug fix was made urgently on a hotfix branch and the same bug also exists in a long-running feature branch. If you merge the hotfix only into main and never into the feature branch, the bug can reappear later when the feature branch is eventually merged.

Merging the fix into the feature branch early avoids that reintroduction.

Common Pitfalls

One common mistake is merging in the wrong direction. If the goal is for the feature branch to receive the hotfix, you should check out the feature branch first and then merge the hotfix into it.

Another mistake is forgetting to fetch before merging a remote branch. That can leave you merging stale local refs.

Developers also sometimes use cherry-pick when they actually want the full hotfix branch history, or use merge when they only needed one small commit. Pick the operation that matches the intent.

Finally, do not skip testing after the merge. Even a small hotfix can interact badly with feature-branch work and produce subtle regressions.

Summary

• To bring a hotfix into a feature branch, check out the feature branch and merge the hotfix branch into it.
• Fetch first if remote refs are involved.
• Resolve conflicts on the feature branch if the hotfix overlaps with in-progress work.
• Use merge for full branch integration and cherry-pick for selected commits.
• Test after the merge so the hotfix does not introduce feature-branch regressions.