Cherry-Picking
Moving fixes between branches
Cherry-picking copies a commit from one branch to another, creating a new commit with the same changes.
When to Cherry-Pick
Primary use case: Bringing fixes from trunk to release branches.
Scenario: Critical bug found after release branch created.
Preferred Flow:
- Fix on trunk first (always)
- Cherry-pick trunk commit to release branch
- Create PR for release branch with cherry-picked commit
Why Fix on Trunk First?
Fixing trunk first is the preferred approach because:
- Ensures fix is in next release
- Avoids regressions in future releases
- Maintains trunk as single source of truth
- Follows "fix-forward" principle
Key Principles
| Principle | Rationale |
|---|---|
| Always fix trunk first | Prevents regressions in future releases |
| Cherry-pick via PR | Maintains audit trail and triggers validation |
| Never skip cherry-pick to trunk | Ensures fix doesn't reappear in next release |
| Same fix, both branches | Divergent fixes cause confusion |
Related Documentation
- Branch Types - Understanding release branches
- Branching Strategies - RA pattern details
- Commit Messages - Conventional commit format
Tutorials | How-to Guides | Explanation | Reference
You are here: Explanation — understanding-oriented discussion that clarifies concepts.