Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Use git cherry-pick to replay one or more chosen commits on the branch you currently have checked out. Start from a clean working tree, verify the commit IDs and destination branch, then run git cherry-pick <commit>. Git normally creates a new commit for each selected change; it does not move the original commit onto the destination branch.
What cherry-pick does—and when to use it
Git describes cherry-pick as applying changes introduced by existing commits. It replays the selected change onto your current branch, producing a new commit object in the destination branch’s history in the usual case. The source commit remains in its original history.
This is useful for moving an isolated bug fix or backporting a particular change to a maintenance branch without integrating an entire feature branch. If you need to integrate a whole branch and preserve its broader relationship with the target, merging or rebasing is generally a better fit than selecting commits one by one. See the Git cherry-pick manual for the command’s behavior and options.
Cherry-pick one commit safely
- Find and inspect the source commit. Use
git logto find its ID, then inspect it withgit show <commit>. Confirm the change is the one you intend to transfer. - Switch to the destination branch. Run
git switch <destination>. Cherry-pick applies changes to the branch currently checked out, not automatically to the branch containing the source commit. - Check your working tree. Run
git status. Commit or stash local work before proceeding; the Git manual requires a clean working tree relative to HEAD. - Apply the commit. Run
git cherry-pick <commit>, replacing the placeholder with the commit ID you inspected. - Review the result. Check the new commit with
git showorgit log, and run the project’s usual tests or checks.
For a practical SHA-to-target-branch workflow, GitLab also documents identifying the commit, checking out the target branch, and running cherry-pick in its cherry-pick guide.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
Cherry-pick several commits or a range
Pick specific commits
Pass multiple commit IDs in the order you want Git to apply them:
git cherry-pick <older-commit> <newer-commit>
Git processes the commits named as arguments; it does not automatically traverse every commit between two IDs. Inspect the changes and order first, especially if a later commit depends on an earlier one.
Pick a commit range
A revision expression such as <base>..<tip> selects commits through a revision walk, so verify the selected list before applying it. For example, inspect the range with git log --oneline <base>..<tip>, confirm it contains the intended commits, then run:
Rank #2
git cherry-pick <base>..<tip>
Range expressions can be easy to misread: the stated base is ordinarily excluded, while commits reachable from the tip and not from the base are included. Check the actual list rather than relying on the shorthand.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsResolve a cherry-pick conflict
If Git cannot apply a commit cleanly, it stops at the current commit. HEAD remains at the last successful commit; Git records the pending commit in CHERRY_PICK_HEAD, applies paths that did not conflict, and marks conflicted files with conflict markers.
- Run
git statusto see which files need attention. - Open each conflicted file, choose or combine the intended changes, and remove the conflict markers.
- Stage each resolved path with
git add <path>. - Continue the operation with
git cherry-pick --continue.
GitLab documents the same resolve, stage, and continue sequence in its cherry-pick guide.
If you decide the current commit should not be applied, use git cherry-pick --skip. To cancel the operation and restore the pre-cherry-pick state, use git cherry-pick --abort. The kernel backporting guide advises aborting and restarting with prerequisite patches when a backport depends on earlier changes: Linux kernel backporting guide.
git cherry-pick --quit clears the sequencer state, but it does not perform the full restoration associated with --abort. Choose it only when you specifically want to clear that state rather than cancel and restore the operation.
Free tools Windows power users keep installed
One-click scans. No signup required.
Cherry-pick a merge commit
A merge commit has multiple parents, so Git cannot determine which parent should serve as the mainline for the replay. Specify the parent number with -m:
git cherry-pick -m <parent-number> <merge-commit>
Parent numbering starts at 1. The selected parent determines which side’s changes Git treats as the baseline for the cherry-pick. Inspect the merge graph and verify the intended mainline before running the command; choosing the wrong parent can produce a different change than you mean to transfer. Both the Git manual and GitLab guide document the mainline option.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Options that change the result
| Option | Effect | When it helps |
|---|---|---|
-n or --no-commit |
Applies the changes to the index and working tree without creating a commit. | Use it when you want to inspect or combine multiple selected changes before making one commit. |
-x |
Appends a “cherry picked from commit …” line to the commit message when the pick has no conflicts. | Useful for backports or other moves between publicly visible branches where recording the source commit aids traceability; the manual says it is unnecessary for private branches. |
--edit |
Lets you edit the commit message before committing. | Use it when the original message needs context for the destination branch. |
--signoff |
Adds a Signed-off-by trailer to the commit message. | Use it when the project’s contribution process requires sign-off. |
--allow-empty |
Preserves commits that were originally empty. | Use it when an intentionally empty source commit still needs to be recorded. |
--empty=drop|keep|stop |
Controls what happens when a commit becomes empty because an earlier pick already supplied its changes. | Choose whether to drop the redundant commit, keep it, or stop for a decision. |
--strategy and -X |
Pass merge-strategy choices for applying the change. | Use only when the ordinary application needs a different strategy or strategy option. |
These options and their detailed behavior are documented in the Git cherry-pick manual.
Quick Recap
Before you finish
- Confirm the destination branch is checked out and
git statusshows a clean working tree before starting. - Verify commit IDs and inspect any range’s exact membership with
git log. - Review the resulting commit or commits and run the project’s normal checks.
- For conflicts, resolve and stage the files before continuing; use
--abortif you need to cancel and restore the pre-operation state.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
