Hotfixes and Backports

Deploying Hotfixes Without Merging Features

After this page you can land a one-commit fix on main and on a release branch without dragging unreleased work.

The situation

feat/big-refactor is half done. Production (main or release/1.x) needs a one-line fix that you already committed on the feature branch.

Merging the feature would ship unfinished work. Cherry-pick the fix commit only.

 feat/big-refactor   A ← B ← fix ← D ← E     (D,E not ready)
 main                A ← B

 cherry-pick fix     A ← B ← fix'            main
                     A ← B ← fix ← D ← E     feat  (untouched)

cd ~/desk/desk-api
git log feat/big-refactor --oneline -5
# copy the hash of the fix

git switch main
git cherry-pick <hash>

Release branch

git switch -c release/1.2 main   # or an existing release line
git cherry-pick <hash>

Now both lines have the fix, as two commits with different hashes and the same author.

Backport the other direction

The fix landed on main first. An older release still needs it:

git switch release/1.1
git cherry-pick <hash-on-main>

If the older tree cannot apply the patch (the surrounding code moved), resolve like a rebase conflict or rewrite the fix by hand and commit normally. Cherry-pick is a tool, not a guarantee.

Label it in the message

git cherry-pick -x <hash>

-x appends (cherry picked from commit …) to the message. Useful on release branches so git log shows the origin hash.

After the pick

Run whatever desk-api uses to check itself on Linux (python -c 'from src.ping import ping; print(ping())' is enough for the toy module). Then merge or push according to chapter 11. Do not merge feat/big-refactor until that feature is done.