Cherry picking commits in Kubernetes is generally done if you want to backport commits from master to a previous release branch.

Suppose a PR that was shipped in v1.32 had a bug. The fix for this bug was pushed in a PR after v1.32 was released. In this case, the bug fix would be merged into the master branch, but the bug would still be present in the release-1.32 branch. In order to push the bug fix in a future patch release for v1.32, you need to cherry-pick the specific commit that fixes the bug from master into the release-v1.32 branch. This is because the release-v1.32 branch would be used for the patch releases, v1.32.1, v1.32.2 and so on.

Running the cherry-pick script

Find the entire guide for cherry picks by SIG Release here.

The cherry_pick_pull.sh script which can be used to automatically generate PRs which cherry pick specific commits into a different release branch is present at hack/cherry_pick_pull.sh.

Running the cherry pick script with the PR number you want to cherry pick from master and the release you want to cherry pick into.

hack/cherry_pick_pull.sh upstream/release-1.32 129946

Some things to note

The cherry pick script assumes that you have the kubernetes/kubernetes remote as upstream and your fork of kubernetes as origin.

For example:

➜ git remote -v

origin	git@github.com:sreeram-venkitesh/kubernetes.git (fetch)
origin	git@github.com:sreeram-venkitesh/kubernetes.git (push)
upstream	git@github.com:kubernetes/kubernetes.git (fetch)
upstream	git@github.com:kubernetes/kubernetes.git (push)

The script would not work if you've not configured your remotes like so.

You'd also need to authenticate the GitHub CLI with your account to be able to automatically open the PR.