Cherry-Pick a Commit Between Git Worktrees

To cherry pick a commit between Git worktrees, commit the fix in the first agent’s worktree, then run git cherry-pick <fix-commit> in the second agent’s worktree. Cherry-pick applies the change introduced by a selected commit to the current branch and normally creates a new commit there. It does not bring over the source branch’s other commits. The two worktrees must belong to the same repository for the local commit to be available without a remote handoff: linked worktrees share repository data while keeping separate working directories, indexes, and HEAD files.

That makes cherry-pick useful when one agent finishes a small fix another agent needs, but neither agent’s whole branch is ready to merge. If you are still deciding how to set up the separate directories, see Git worktrees explained.

Make the fix a commit first

Cherry-pick transfers a committed change, not the source agent’s uncommitted edits. Ask the source agent for a focused commit containing the fix, its relevant tests, and any files required for the fix to work. Keeping unrelated edits out of that commit makes the handoff easier to review and less likely to conflict.

For example, suppose the main worktree and both agent worktrees are sibling directories: ../agent-fix is on branch agent/fix-validation, while ../agent-feature is on agent/add-endpoint. From the main worktree’s root, list the worktrees and check the source worktree:

git worktree list
cd ../agent-fix
git status --short

The short status format shows changed and untracked paths. If the fix is still among other working changes, git add -p lets you choose individual hunks to stage. Stage any required new files by path, review the staged diff, and make a commit:

git add -p
git diff --cached
git commit -m "Fix validation"

git diff --cached shows staged changes against HEAD, and git commit -m supplies the new commit’s message. Check the staged diff before committing: an incomplete fix is no more useful to the other agent just because it has a commit ID. If the source agent already made a focused commit, leave its branch alone and identify that commit instead.

Identify exactly what the other agent needs

From the source worktree, list commits on the source branch that the target branch does not already contain:

git log --oneline agent/add-endpoint..agent/fix-validation

The A..B revision range lists commits reachable from B but not A, and --oneline abbreviates each entry. This is a list of candidates, not a command to copy them all. Find the focused fix commit, then inspect it:

git show --stat <fix-commit>
git show <fix-commit>

git show displays a commit’s message and patch, while --stat gives a file summary. Check whether the patch includes generated files, configuration changes, or a prerequisite from an earlier source commit. A cherry-pick replays the selected commit’s change; it does not automatically bring along commits that made that change possible.

If the fix is the source branch’s tip, its branch name can stand in for the commit ID. An explicit commit ID is clearer for an agent handoff: it still identifies the intended change if the source agent makes another commit before the target agent acts.

Apply the commit in the receiving worktree

Move to the receiving agent’s worktree and check its status before starting. A normal cherry-pick requires a clean working tree, so finish or set aside current edits first. Coordinate with the receiving agent so it does not edit that worktree during the operation.

cd ../agent-feature
git status --short
git cherry-pick <fix-commit>
git show --stat HEAD

The last command lets you inspect the resulting commit. Cherry-pick normally creates a new commit on agent/add-endpoint; the original remains on agent/fix-validation. Tell the receiving agent which fix was brought in and have it run the target branch’s relevant tests. A clean application only means Git could apply the patch; it does not establish that the combined code behaves correctly.

A concise handoff instruction is: “In agent/add-endpoint, cherry-pick <fix-commit>, inspect the resulting diff, resolve any conflicts without discarding the endpoint work, and run the relevant tests.” Give the agent the commit ID and the reason for the fix. Avoid asking it to merge the entire source branch when only this change is needed.

Resolve a conflict without losing either agent’s work

A cherry-pick can stop when the selected change cannot be applied cleanly. Git leaves the current branch at the last successfully applied commit, records the commit being picked in CHERRY_PICK_HEAD, and marks conflicted paths in the index and working files. In the receiving worktree, inspect the conflict:

git status
git diff

Edit each conflicted file into the version that should exist on the receiving branch. Keep the source fix and the target agent’s intended behavior where both are needed; deleting one side’s code merely to remove conflict markers can produce a plausible but broken result. Then stage the resolved paths and continue:

git add <resolved-path>
git diff --cached --check
git cherry-pick --continue

git diff --check warns about introduced conflict markers and whitespace errors; using it with --cached checks the staged resolution. Inspect the final commit and run the receiving branch’s relevant tests after the cherry-pick completes. If the transfer is wrong or the conflict needs a broader design decision, git cherry-pick --abort returns to the state before the sequence. Use --skip only when you have decided that the current commit should be omitted, such as a change already present in the target.

Handle dependencies and larger changes deliberately

A fix may depend on a helper, schema change, or interface introduced by another source commit. If inspection reveals such a prerequisite, identify and review that commit too. Apply prerequisites before the dependent fix:

git cherry-pick <prerequisite-commit>
git cherry-pick <fix-commit>

Review the target branch after each step. This preserves separate commits and makes the dependency visible. If the prerequisite also drags in unrelated work, ask the source agent to prepare a narrower commit rather than copying a broad branch history into the receiving worktree.

For several closely related commits that you want to review as one combined change, git cherry-pick --no-commit <commit> applies a commit to the working tree and index without immediately creating a commit. You can apply another selected commit the same way, inspect git diff --cached, and then commit the combined result. This gives you control over the final commit boundary, but it also means you must supply the final message and verify that the combined staged change is complete. The default cherry-pick, with one resulting commit per selected source commit, is usually easier to trace.

A merge commit needs special care. Git normally cannot cherry-pick one without --mainline <parent-number>, which tells it which parent to compare against. Prefer the focused non-merge commit that introduced the fix when one exists. If the source commit contains the fix mixed with unrelated edits, making a clean source commit is generally clearer than trying to untangle that large patch during the transfer.

Cherry-pick is a handoff, not branch integration. The receiving branch gets the chosen change while the remaining source commits stay on their branch. When the larger tasks are complete, decide how to integrate the branches with full knowledge of what was already copied; merging parallel agent branches covers that later step.

Where Parallel Code fits

Parallel Code is our free, open-source (MIT) desktop app for macOS and Linux. It runs several AI coding agents in parallel, each in its own git worktree, and provides a diff-first review surface. You can use the Git commands above to pass a finished commit between those worktrees while reviewing each agent’s work separately.

Frequently asked questions

Can I cherry-pick uncommitted changes from another worktree?

No. Cherry-pick takes an existing commit, so have the source agent make a focused commit first. If its working directory contains several tasks, stage and review only the fix and the files it requires.

Do I run cherry-pick in the source or destination worktree?

Run it in the destination worktree, on the branch that needs the fix. You can inspect the source commit from either linked worktree because they belong to the same repository, but the branch receiving the new commit is the one checked out where you run cherry-pick.

Will cherry-pick merge the other agent’s branch?

No. Selecting one commit applies that commit’s change to the current branch; it does not select the rest of the source branch. Inspect dependencies first, because an isolated patch can apply successfully while still relying on code that the destination branch lacks.

What if Git says the cherry-pick is empty?

Inspect the target branch before acting: the change may already be present. Git’s default is to stop when a previously nonempty commit becomes redundant; if it is safe to omit that commit, use git cherry-pick --skip to continue the sequence.