pr-backport

Cherry-pick merged pull requests into release branches with conflict resolution and validation.

6.2k|596|Updated May 5, 2016
One-click install
npx skills add https://github.com/RediSearch/RediSearch --skill pr-backport
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pr-backport
Source: https://github.com/RediSearch/RediSearch/tree/main/.skills/pr-backport
Command: npx skills add https://github.com/RediSearch/RediSearch --skill pr-backport

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Backporting a merged PR to older release branches is error-prone: cherry-picks conflict, unrelated tests sneak in during conflict resolution, and RDB or config compatibility issues are easy to miss. This Skill guides the entire backport workflow from identifying the squash-merged commit to opening validated backport PRs.

Core Features & Use Cases

  • Isolated worktree setup: Creates per-branch git worktrees and dedicated backport branches so release checkouts stay clean and pushes are safe.
  • Ordered multi-branch backports: Processes release lines newest-to-oldest (e.g., 8.8 before 8.2) so conflict resolutions on newer branches inform older ones.
  • Compatibility verification: Checks RDB serialization versions, command/API surface, and config options against the target branch before building.
  • Use Case: A bug fix merged to master as PR #8774 must ship in the 2.10, 8.2, and 8.6-rse maintenance releases. The Skill cherry-picks the commit into each branch, resolves conflicts while excluding unrelated tests, builds and runs tests, then opens one backport PR per branch.

Quick Start

Ask the assistant to backport PR 8774 to branches 8.6-rse, 8.2, and 2.10 using the pr-backport skill.

Frequently Asked Questions about pr-backport

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I backport a merged PR to a release branch?

Find the squash-merged commit with gh pr view or git log, create a worktree and dedicated backport branch from the target release branch, then cherry-pick the commit. Build, run tests, and open a PR targeting the release branch.

How to cherry-pick a PR to multiple branches at once?

Process branches newest-to-oldest (for example 8.8 before 8.2), using a separate git worktree and backport branch per target. Resolutions from newer branches often apply to older ones, and each branch gets its own backport PR.

Why do cherry-pick conflicts pull in unrelated tests?

Test directories are append-heavy, so conflicts often surface tests added by other features merged after the branch point. Verify with git show <sha> -- <test_file> which test additions belong to the original PR and drop everything else.

What compatibility checks are needed when backporting Redis module changes?

Check RDB encoding versions if the PR touches serialization code, confirm new commands or arguments exist on the target branch, and verify config options in src/config.c are supported. Older branches may only accept the bug fix, not new features.

Should I cherry-pick directly on the release branch?

No. Create a dedicated backport branch inside an isolated git worktree based on the latest target branch. This keeps the release checkout clean and makes the final push and PR creation safe.