Q: A critical bug-fix commit exists on `develop` and you need exactly that one commit on a release branch — without bringing along the other 50 commits on `develop`. How do you do it, and what could go wrong?

This is git cherry-pick:

• Conflicts — if the surrounding code on release/1.4 is different from develop, the patch may not apply cleanly. Resolve, then git cherry-pick --continue.
• Missing dependencies — the commit may rely on a refactor or a helper that was introduced in an earlier commit on develop but isn't on release/1.4. The cherry-pick may apply but the code won't compile or behave correctly. You may need to cherry-pick the prerequisite commit too, or write a backport patch.
• Duplicate-looking commits — when develop is later merged into release (or vice versa), Git usually figures out the commits are equivalent (via patch-id), but in some workflows you can end up with two commits doing the same thing under different SHAs. Use git cherry-pick -x to record "(cherry picked from commit …)" in the message — invaluable later for traceability.

Cherry-pick takes the diff that commit introduced and applies it as a *new* commit on the current branch (new SHA, same content). For multiple commits: git cherry-pick or a range git cherry-pick A..B. What can go wrong: For ongoing back-port flows (fix on main, port to release/*), some teams prefer a dedicated hotfix/* branch that's merged into both, which avoids cherry-picks entirely.

git switch release/1.4
git cherry-pick <commit-sha>
git push