info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
comments:false
---
# Cherry Pick
Given an existing commit on one branch, apply the change to another branch.
This can be useful for backporting bug fixes to previous release branches. Make
the commit on the default branch, and then cherry pick it into the release branch.
## Sample workflow
1. Check out a new `stable` branch from the default branch:
```shell
git checkout master
git checkout -b stable
```
1. Change back to the default branch:
```shell
git checkout master
```
1. Make any required changes, then commit the changes:
```shell
git add changed_file.rb
git commit -m'Fix bugs in changed_file.rb'
```
1. Review the commit log and copy the SHA of the latest commit:
```shell
git log
```
1. Check out the `stable` branch:
```shell
git checkout stable
```
1. Cherry pick the commit by using the SHA copied previously:
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
comments:false
---
---
# Cherry Pick
This document was moved to [another location](../../../topics/git/cherry_picking.md).
- Given an existing commit on one branch, apply the change to another branch
<!-- This redirect file can be deleted after <2021-06-01>. -->
- Useful for backporting bug fixes to previous release branches
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
- Make the commit on the master branch and pick in to stable
## Cherry Pick sample workflow
1. Check out a new 'stable' branch from 'master'
1. Change back to 'master'
1. Edit '`cherry_pick.rb`' and commit the changes.
1. Check commit log to get the commit SHA
1. Check out the 'stable' branch
1. Cherry pick the commit using the SHA obtained earlier