--- title: "Git Cherry-Pick Release Strategy" type: "Skill" slug: "git-cherry-pick-strategy" icon: "commit" category: "Developer Tools" tags: ["Git", "Release Management", "Cherry-pick", "DevOps", "Branching", "Version Control"] installs: "0" author: "Andreas Beasley" authorInitial: "A" lastUpdated: "2026-04-02" popularity: "5.0/5" reviewCount: "New" platformTags: ["v1.0", "Internal"] installLabel: "CLI" securityBadges: - label: "Data Handling" status: "No PHI — git metadata only" - label: "Scope" status: "Internal Developer Use" --- # Git Cherry-Pick Release Strategy Step-by-step process for comparing branches, grouping commits by criticality, and building cherry-pick commands for selective release management — without pulling in all unreleased staging work. ## When to Use Use this skill when you need to: - Compare two branches and list commits present in one but not the other - Cherry-pick specific commits into a release branch for a targeted patch release - Assess the criticality of pending changes before a release cut - Filter out staging merge wrappers and branch-sync commits from a candidate list - Build a cherry-pick command ordered oldest → newest with conflict-risk grouping - Confirm and execute a cherry-pick plan interactively, step by step ## Installation ```bash auggie skill add https://aidiscoveryportal.azurewebsites.net/api/skills/git-cherry-pick-strategy ``` ## Tool Definition ```json { "name": "git_cherry_pick_strategy", "description": "Guides a step-by-step cherry-pick release strategy: compares a source branch (e.g. staging) against a release branch, filters out staging merge wrappers and branch-sync commits, groups candidates by criticality using Jira priority and file-risk signals, and builds an ordered cherry-pick command for interactive confirmation before execution.", "input_schema": { "type": "object", "properties": { "sourceBranch": { "type": "string", "description": "The branch containing commits to cherry-pick from (e.g. 'staging', 'origin/staging')." }, "releaseBranch": { "type": "string", "description": "The release branch to cherry-pick into (e.g. 'release/release-1.0.41'). Accepts a version string like '1.0.41' and resolves it to the full branch name." }, "autoExecute": { "type": "boolean", "description": "If true, execute the confirmed cherry-pick command after user approval. Defaults to false — always ask before running git commands." } }, "required": ["sourceBranch", "releaseBranch"] } } ``` ## Step-by-Step Process ### Step 0 — Pre-Flight Checks Ensure the local state is fresh before any comparison. ```bash # Fetch all remote refs so comparisons are up to date git fetch --all # Confirm no uncommitted changes exist git status # Confirm the release branch exists remotely git branch -a | grep ``` > ⚠️ Never compare branches without fetching first — stale refs produce incorrect diff output. --- ### Step 1 — List Commits in Source Not in Release Use `--cherry-mark` to flag commits already equivalent in both branches: ```bash git log origin/ --not origin/ --oneline --cherry-mark ``` - `+` prefix = unique to source → candidate for cherry-pick - `=` prefix = equivalent already in release → skip --- ### Step 2 — Separate Feature Commits from Merge Wrappers This repo uses a double-PR merge pattern. Each change produces: - **Feature commit** — the actual code change (e.g. `Merged PR 30695: proper find`) - **Staging merge wrapper** — merges `main → staging` (e.g. `Merged PR 30696: Merged PR 30695: proper find`) **Only cherry-pick feature commits.** Filter out wrappers and branch-sync merges: ```bash git log origin/staging --not origin/release/release-X.X.XX --oneline \ | grep -v "Merged PR.*Merged PR" \ | grep -v "main > staging" ``` --- ### Step 3 — Inspect All Feature Commits in Bulk Gather changed files and Jira ticket context for every candidate commit at once: ```bash for hash in ; do echo "=== $hash ===" git show $hash --stat | grep " |" done ``` Then batch-query any Jira tickets referenced (e.g. `MP-XXXX`) in a single JQL call: ``` jql: "key in (MP-XXXX, MP-YYYY, MP-ZZZZ)" fields: summary, status, priority, issuetype, description ``` --- ### Step 4 — Group Commits by Type and Criticality | Group | Criteria | Include by Default | |-------|----------|--------------------| | **Critical / P0** | Jira priority = Highest/Critical, auth/session bugs, production incidents | No — list for manual review | | **Interconnected Chain** | Multiple commits touching the same files in sequence | No — include all or none | | **Medium Bugs** | Jira priority = Medium, data/export bugs with tickets | Yes | | **UI Polish** | Styling, copy, margin tweaks — no functional impact | Yes | | **Logging Only** | Adds observability, no behavior change | Yes | > If commits touch the **same files** across sequential PRs, treat them as a dependent chain — never partially cherry-pick a chain. --- ### Step 5 — Present the Plan for Review **Part A — Default command** (non-critical commits, ordered oldest → newest): ```bash git cherry-pick -x ... ``` **Part B — Excluded commits** (Critical / Interconnected chains — listed for manual decision): ``` ⚠️ The following commits were NOT included above. Review and confirm inclusion: [1] a1b2c3d — MP-2244: Fix session redirect loop (P0 / Highest) Files: src/app/(session)/session/expired/refresh/page.tsx Risk: Auth/session — high impact if excluded [2] b2c3d4e — PatientDetailsDialog: initial implementation (chain of 4) Files: src/components/ui/PatientDetailsDialog.tsx, ... Risk: Include all 4 or none — partial inclusion will cause build errors ``` --- ### Step 6 — Interactive Confirmation Ask before executing: 1. **Adjustments** — "Would you like to add or remove any commits? Reference by number, hash, or description." 2. **Execute** — "Here is the final command. Shall I run this on `release/release-X.X.XX` now?" Only proceed after explicit user confirmation. --- ### Step 7 — Execute on the Release Branch ```bash git checkout release/release-X.X.XX git cherry-pick -x ... ``` **If a conflict occurs:** ```bash git status # identify conflicting files # resolve conflict markers manually git add git cherry-pick --continue # resume the sequence # or: git cherry-pick --skip (skip this commit) # or: git cherry-pick --abort (abandon everything, restore original state) ``` --- ### Step 8 — Verify Before Pushing ```bash git log --oneline -15 ``` Confirm the expected commits landed in the correct order. --- ### Step 9 — Push Ask for final confirmation, then: ```bash git push origin release/release-X.X.XX ``` --- ## Commit Message Patterns (QualityIQ) | Pattern | Meaning | |---------|---------| | `Merged PR XXXXX: Merged PR XXXXX: ...` | Staging merge wrapper — **skip** | | `Merged PR XXXXX: main > staging` | Branch sync merge — **skip** | | `Merged PR XXXXX: ` | Feature commit — cherry-pick candidate | | `MP-XXXX: ` | Direct Jira-linked commit | | `fix: ` | Conventional commit bug fix | | `feat: ` | Conventional commit feature | ## When NOT to Cherry-Pick Prefer a **full merge** instead when: - Staging is only 3–5 commits ahead of release — a merge avoids duplicate history - **All** staging commits are intended for the release - Commits are deeply interdependent across many files — merge conflicts are easier to reason about in a merge than mid-cherry-pick ## Tips - **Always fetch first** — comparing stale refs is the most common source of incorrect cherry-pick lists. - **The double `Merged PR` pattern** is the reliable signal for staging wrappers — not PR number parity or even-vs-odd numbering. - **Interconnected chains** carry the highest conflict risk. If one commit in a chain fails, resolve it before continuing — never skip mid-chain. - **Jira priority** is the primary criticality signal: Highest/Critical = must evaluate; Medium = optional; Low = freely include. - **Auth/session files** (`proxy.ts`, `session/`) have outsized production impact — flag them as high risk even if Jira priority is unset. ## Example Prompts > "Which commits are in staging but not in release 1.0.41?" > "Build a cherry-pick command for the medium-priority bug fixes from staging into release/release-1.0.41." > "Show me the criticality breakdown of everything ahead of release 1.0.40 in staging." > "I want to add the PatientDetailsDialog chain to the cherry-pick command we built — include all four commits." > "Push the release branch once we've confirmed the cherry-picks look good."