How do you get a hotfix committed on a release branch back into main, and what breaks if you don't?

## Why the fix does not travel by itself When you cut `release/1.4` from `main`, you create a second line of development in the commit DAG. A commit made on the release branch is a child of a release-branch commit; nothing on `main` points at it, so it is unreachable from `main`. Git has no notion of "this fix logically belongs everywhere" — reachability is the only thing it tracks. The fix reaches `main` when, and only when, some human action makes it reachable there. The failure mode is delayed and embarrassing. The hotfix goes out in 1.4.1, the incident closes, and six weeks later 1.5.0 is cut from `main` — which never received the fix — and ships the same bug to the same customers. Because the code looks "already fixed" in everyone's memory, this regression is usually diagnosed twice. ## Option 1: merge the release branch back `git switch main && git merge release/1.4` creates a merge commit whose second parent is the release tip. Properties worth stating in an interview: - **Containment becomes provable.** After the merge, `git branch --contains <sha>` lists `main`, and `git tag --contains <sha>` lists every release tag that includes it. This is the strongest thing Git can tell you about propagation, because it is graph reachability rather than text similarity. - **Future merges get cheaper.** The merge base between the two lines advances, so the next merge only has to consider work done since. - **Everything on the branch comes along**, including release-only commits such as version-string bumps, changelog edits or a temporary configuration pin. If those do not belong on `main`, the merge drags them in and someone has to revert them — and a revert on `main` will then be inherited by the *next* release branch, which is a whole second class of confusion. ## Option 2: cherry-pick the individual commit `git switch main && git cherry-pick -x <sha>` applies that commit's change on top of `main` as a **new commit with a new id**. The content is equivalent; the identity is not. `-x` appends a `(cherry picked from commit <sha>)` trailer to the message, which is the only durable trace linking the two — use it always for cross-branch propagation, because six months later that line is how someone answers "where did this come from". Cherry-picking is the right tool when the release branch carries material that must not reach `main`, or when only one of several commits on the branch is wanted. The cost is that reachability no longer answers the containment question: `git branch --contains <original-sha>` will not list `main`, even though the fix is there. ## Auditing what has and hasn't crossed Because cherry-picks break reachability, Git offers patch-id-based comparison. `git cherry -v main release/1.4` lists commits on `release/1.4` and marks each `+` (no equivalent change exists on `main`) or `-` (an equivalent change is already there). Equivalence is computed from a *patch id* — a hash of the diff with whitespace and line numbers normalised — so an unmodified cherry-pick is detected, while a cherry-pick that needed conflict resolution may not be. `git log --oneline --cherry-pick --right-only main...release/1.4` gives the same information as a filtered log. Making a `+`-list review part of closing a release is how teams stop losing fixes. ## Which direction, and in what order The habit worth internalising: **fix on the oldest line that has the bug, then propagate forward**. Fixing on `main` first and then backporting is tempting because `main` is where people work, but it means the urgent line is patched last and the merge direction is now backwards. When there is only one release line, either order works as long as somebody actually does the second step; the discipline is what matters. A related conflict trap: if the same fix is applied independently on both lines — hand-written twice, or cherry-picked and then also merged — the subsequent merge will often conflict, because Git sees two different commits touching the same lines with no common ancestor for that change. `rerere.enabled = true` records your resolutions so a repeatedly re-encountered conflict resolves the same way each time. ## Making it hard to forget The organisational answer is that propagation is part of the fix, not a follow-up task: the hotfix is not "done" until it is on `main`, and the release checklist ends with a `git cherry` audit rather than a memory. Server-side hooks can reject a push to a release branch that has no counterpart, but the durable fix is the checklist plus the audit command — mechanisms that report the truth about the graph rather than about intentions.