Cherry-pick

Cherry-pick applies the patch introduced by one or more commits onto the current branch. The new commit gets a **different hash** even when the diff matches — it is not the same object as the source commit.

					git switch release/2.0
git cherry-pick abc1234
git cherry-pick main~3..main   # range (exclusive..inclusive rules apply)
				

Practical for hotfixes, release backports, and recovering a focused change without merging unrelated history. Order matters when commits depend on each other.

On interviews: duplicate commit identity across branches, conflict handling, backport verification, and when a normal merge is safer.

Common pitfalls: cherry-picking dependent commits out of order compiles but behaves wrong; skipping tests on backports; using cherry-pick to avoid understanding merge conflicts.

The trade-off is surgical change transfer versus merge integrity and full context.

Checklist:

• Pick focused, independent commits when possible.
• Verify dependencies between commits in a range.
• Run the same tests and release notes process as normal merges.
• Prefer merge when the branch context is required.