Merge a hotfix into a feature branch

Switch to the feature branch and merge the hotfix branch into it. This brings both the fix and its ancestry into the feature branch, which is often appropriate when several developers share that branch.

Bring in the fix

Start with a clean working tree or preserve unfinished work separately:

git fetch origin
git switch feature-x
git merge origin/hotfix-login-fix

If Git reports conflicts, edit the affected files, stage the intended resolutions, and finish the merge with git commit. Run the feature's tests and the hotfix regression test before publishing:

git push origin feature-x

If the hotfix has already reached main, merging origin/main may be the better choice: it brings the feature branch up to date with all accepted changes. Check that the hotfix remote-tracking branch still exists before selecting it.

Choose between merge and rebase

A merge preserves existing commit identities. It creates a merge commit when the histories diverge, but can fast-forward when one tip is an ancestor of the other.

Rebasing a private feature branch onto the hotfix is another option. It replays feature commits and changes their identities. Avoid rewriting a shared feature branch without coordination; publishing rewritten history may require a permitted force-with-lease push.

Take just one commit with cherry-pick

git cherry-pick HOTFIX_COMMIT

Replace HOTFIX_COMMIT with the actual commit ID. Cherry-pick applies that commit's change without establishing the same ancestry as a merge. Confirm that it does not depend on other hotfix commits. Merge commits require a deliberate mainline choice and should not be treated as ordinary single commits.

When the original fix later arrives through another branch, matching content may merge cleanly, but duplicate changes and later edits can still cause conflicts. An empty-patch stop can occur during cherry-pick or rebase; it is not a universal result of an ordinary merge.

Plan the next integration

Sync promptly when the hotfix touches the feature's behavior; otherwise follow a regular integration cadence. Shared ancestry helps Git avoid reapplying the same historical change, but it cannot guarantee that the final merge is conflict-free. Different later edits can conflict, and code that merges cleanly can still behave incorrectly.

A hotfix need not reach main first to be merged into the feature. However, if its history is subsequently amended or rebased, the feature retains the earlier commits. Coordinate the replacement rather than assuming both versions are interchangeable.

References: git merge, git rebase, and git cherry-pick.