cherry-pick-release

name	cherry-pick-release
description	Create a release branch from main, cherry-pick specific commits from test, and validate the result. Use when preparing a production release by cherry-picking commits, checking scope and parity with the test branch.

Cherry-Pick Release Skill

Purpose

Create a release branch from main, cherry-pick commits from test, and validate the result is clean and complete before merging to production.

Workflow

1. Prepare

git fetch origin
git checkout main && git reset --hard origin/main

2. Create release branch

git checkout -b release/<feature-name>

Use the feature/ticket name provided by the user.

3. Cherry-pick commits

User provides commit SHAs (from test branch). Apply them in chronological order:

git cherry-pick <sha1> <sha2> ...

If conflicts arise, stop and ask the user — never auto-resolve.

4. Validate scope (PR diff check)

Verify the diff against main only touches files related to the feature:

git diff origin/main...HEAD --stat
git diff origin/main...HEAD --name-only

• Review the file list. Flag any file that doesn't belong to the feature.
• If unexpected files appear, warn the user — likely a missing dependency or wrong commit.

5. Validate parity with test

Ensure cherry-picked changes produce the same result as on test. For each changed file, compare the file content on the release branch vs origin/test:

# For each file in the diff:
git diff HEAD:<file> origin/test:<file>

• No diff = good — change is identical on both branches.
• Diff exists = investigate. Possible causes:
  • Missing commit (need more cherry-picks)
  • Commit on test was amended/squashed differently
  • File has other unrelated changes on test (expected, safe to ignore if only surrounding context differs)
• Report findings to the user with a summary table:

File	Status	Notes
module/main.tf	✅ identical
module/variables.tf	⚠️ differs	lines X-Y differ, likely unrelated change on test

6. Terraform validation (optional, recommended)

If the change touches Terraform modules:

make tf-fmt
make plan ENVIRONMENT=test TF_TARGET='module.<name>'

7. Final summary

Report to the user:

• Branch name and commit count
• Files changed (scoped to feature: yes/no)
• Parity with test (all matching / issues found)
• Ready to push: yes/no

Key Rules

• Never force-push to main or test.
• Never auto-resolve cherry-pick conflicts.
• Always validate both scope and parity before declaring ready.
• Commits must be provided by the user — don't guess which commits to pick.