Cherry-Picking a Commit in TortoiseGit Without Touching the Command Line

You just spotted the fix you need sitting on a feature branch that isn't ready to merge. The whole branch would drag in half-finished work, but that one commit is exactly what production needs. TortoiseGit's cherry-pick command solves this in about four clicks — no command line, no copying commit hashes by hand.

The takeaway: right-click any commit in the log, choose cherry-pick, and TortoiseGit applies that change as a new commit on your current branch. The rest of this post covers how to do it safely, what happens when it conflicts, and the one mistake that makes cherry-picking painful later.

What cherry-pick actually does

Cherry-picking copies the changes from a commit, not the commit itself. Git applies the diff to your working tree and creates a brand-new commit on your current branch, with a new hash. The original commit stays untouched where it was. This matters because two commits with identical changes but different hashes are, as far as Git is concerned, unrelated — which becomes relevant when you eventually merge the branches.

Before you start, make sure your working tree is clean. Commit or stash any pending changes first. Cherry-pick modifies files in your working directory, and mixing it with uncommitted work is the fastest way to lose track of what came from where.

The worked example: pulling a hotfix across branches

Say you're on main and a colleague fixed a null-check bug in commit a3f9c21 on the feature/search branch. Here's the flow:

1. Fetch first. Right-click in your repo folder → TortoiseGit → Fetch (or Pull). If the commit lives on a remote branch you haven't fetched, it won't appear in your log. This is the step people skip and then wonder why the commit is missing.
2. Open the log. Right-click → TortoiseGit → Show Log. By default the log shows your current branch; use the branch filter dropdown in the top-left to select feature/search or "All branches" so you can see the commit you want.
3. Switch back mentally, not literally. Confirm in the log window's header or in the Explorer context menu that your checked-out branch is still main. Cherry-pick applies to whatever branch is currently active — viewing another branch in the log does not change your checkout.
4. Cherry-pick it. Right-click the commit a3f9c21 → TortoiseGit → Cherry Pick. Confirm the dialog. TortoiseGit applies the changes and opens a commit dialog pre-filled with the original message and author.
5. Verify. Reopen the log on main. You should see a new commit at the tip with the same message and author as the original, but a different hash.

If you prefer the terminal for verification, run git log --oneline -5 in the repo directory. The new commit should be at the top, and running the same command on feature/search should show the original commit unchanged.

When it conflicts

If the target branch has diverged — say main already touched the same lines the hotfix modifies — TortoiseGit stops and opens its conflict resolution flow. You'll see the conflicted files listed, and double-clicking one launches the three-way merge tool showing the base version, your branch's version, and the incoming change.

Resolve each file, mark it resolved, then continue the cherry-pick. If it goes sideways, you can abort entirely and your branch returns to its pre-cherry-pick state. That escape hatch is worth remembering: a half-resolved cherry-pick is worse than none at all.

The trade-off: duplicate changes at merge time

Cherry-picking is convenient but creates a fork in your history. When you eventually merge feature/search into main, Git sees the cherry-picked changes and the original commit as separate. Git is usually smart enough to recognize identical changes and merge cleanly, but if either side has since modified those lines, you can get conflicts on code you thought was already settled.

Practical guidance: cherry-pick for genuine one-offs (hotfixes, backports to release branches that will never merge back). If you find yourself cherry-picking five commits from the same branch, that's a signal you should be merging or rebasing instead. And never cherry-pick the same commit twice onto the same branch — you'll get duplicate commits and a confusing history.

Version notes

The streamlined right-click cherry-pick entry in the log context menu has been available since TortoiseGit 2.13. If you're on an older version, the same operation exists but may require the Sync dialog or command line. Check your version under TortoiseGit → About if the menu entry is missing.

The actionable close: next time you need one commit from an unready branch, fetch, open the log, right-click, cherry-pick — then verify the new hash at your branch tip and note the duplicate-history risk for your next merge.