# Pr Backport

> Backport a merged PR to a release branch. Use this when you need to cherry-pick a fix or feature into an older branch.

- Skill: `redisearch/pr-backport` (Agent Skill)
- Install (CLI): `npx skillmds@latest add redisearch/pr-backport`
- Raw SKILL.md: https://api.skillmd.com/api/skills/redisearch/pr-backport/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: RediSearch (https://skillmd.com/u/redisearch)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/redisearch/pr-backport

---


# PR Backport

Backport a merged PR to one or more release branches.

## Arguments

`$ARGUMENTS` should contain:
- The PR number or commit SHA(s) to backport
- The target branch(es) (e.g., `2.10`, `8.2`, `8.6-rse`, `8.8`)

Example: `/pr-backport pr:8774 8.6-rse 8.2 2.10`

## Instructions

### 1. Identify the source commit

PRs are squash-merged via the merge queue, so each PR lands as a single commit on master.
Find that commit:

```bash
gh pr view <number> --json mergeCommit
```

Or search the log:
```bash
git log --oneline --grep="#<number>" master
```

Read the PR description to understand the change and any compatibility considerations.

### 2. Set up worktrees and backport branches

For each target branch, create a worktree if one doesn't already exist, then create
a dedicated backport branch. Do not cherry-pick directly on the release branch.
The worktree keeps each target release checkout isolated; the dedicated backport
branch is what makes the final push and PR safe.

```bash
git fetch origin <branch>
git worktree add .worktrees/backport-<branch> origin/<branch>
cd .worktrees/backport-<branch>
git checkout -b backport/pr-<number>-to-<branch>
```

If a worktree already exists for that branch, reuse it after confirming it is clean:

```bash
cd .worktrees/backport-<branch>
git status --short
git fetch origin <branch>
git checkout -b backport/pr-<number>-to-<branch> origin/<branch>
```

If the backport branch already exists, check it out instead and verify it is based
on the updated target branch before cherry-picking.

### 3. Cherry-pick

For each target release line, start with the newest version closest to master and
work backward. For example, process `8.8` before `8.6`, `8.6` before `8.4`,
and `8.4` before `8.2`.

Treat same-version variants such as `8.6` and `8.6-rse` as peers; process them
in whichever order is more practical for the backport or follows team convention.

```bash
cd .worktrees/backport-<branch>
git branch --show-current  # should be backport/pr-<number>-to-<branch>
git cherry-pick <sha>
```

If cherry-pick produces conflicts:
- Read the conflict markers carefully.
- Understand what changed on the target branch vs. master since the PR was merged.
- Resolve the conflicts, preserving the intent of the original fix.
- Common conflict sources:
  - Code that was refactored differently on the target branch.
  - Features that don't exist on the target branch (remove references to them).
  - Config options or struct fields added after the branch point.
- **Beware of unrelated tests sneaking in via conflict resolution.** Test files
  (e.g. `tests/pytests/`, `tests/cpptests/`) are append-heavy, so conflicts there
  often surface tests added by *other* features that landed on master between the
  branch point and the PR. When resolving, only keep the tests that were part of
  the original PR — verify against `git show <sha> -- <test_file>` to see exactly
  which test additions belong to this backport, and drop anything else that the
  conflict markers pulled in.

### 4. Verify compatibility

After resolving conflicts, check for issues specific to backports:

**RDB serialization**: if the PR touches `src/rdb.c` or serialization code, verify that
the encoding version on the target branch is compatible. The target branch may have a
different RDB version than master.

**API surface**: if the PR adds new Redis commands or command arguments, verify that the
target branch supports them. Some features may not exist on older branches and the
backport should only include the bug fix, not the new feature.

**Config**: if the PR adds or modifies config options in `src/config.c`, verify that the
config parameter exists on the target branch.

### 5. Build and test

```bash
cd .worktrees/backport-<branch>
./build.sh FORCE
./build.sh RUN_UNIT_TESTS ENABLE_ASSERT=1
```

If the original PR includes specific test files, run those:

```bash
./build.sh RUN_PYTEST TEST=<test_file>
```

### 6. Create the backport PR

Before publishing anything, summarize the source PR/commit, target branch, backport branch,
files changed, validation results, and PR title/body. Ask the user to confirm before running
`git push` or `gh pr create`.

```bash
cd .worktrees/backport-<branch>
git push -u origin backport/pr-<number>-to-<branch>
gh pr create \
  --base <branch> \
  --head backport/pr-<number>-to-<branch> \
  --title "[<branch>] <original PR title>" \
  --body "Backport of #<original PR number> to <branch>.

## Original PR
<link to original PR>

## Changes from original
<describe any modifications needed for the backport, or 'Clean cherry-pick, no changes needed.'>
"
```

### 7. Multi-branch backports

When backporting to multiple branches, use the same newest-to-oldest release-line
order described above. Conflicts tend to be simpler on newer branches, and the
resolution strategy from a newer branch often applies to older branches too.

Report a summary for each target branch:
- Clean cherry-pick or conflicts resolved
- Build status
- Test status
- PR link