There is no git worktree pull, and you don't need one

Canonical version: There is no git worktree pull, and you don't need one.

I'm using Git worktrees more and more, mostly because every parallel coding agent needs its own working directory. And sooner or later, you hit the question from this Stack Overflow thread: I changed something in worktree A, how do I get it into worktree B? Is there a git worktree pull?

No. And once you understand why, the answer becomes obvious.

All worktrees share the same .git repository: same objects, same branches, same refs. There's no "remote" between them, so there's nothing to pull. A commit made in one worktree is instantly visible in all the others. What's NOT shared is the uncommitted stuff: your working files and your staging area. That's the part the person asking wanted to move, because they didn't want to commit untested changes.

Three ways to do it, depending on where your changes are:

• Uncommitted changes: make a patch and apply it. git diff > /tmp/changes.patch in the first worktree, then git apply /tmp/changes.patch in the second one. You can limit it to a few files with git diff -- file1 dir/file2. Or skip the file entirely: git -C ../main diff | git apply
• Committed changes: just git cherry-pick <sha> (or git merge/git rebase the other branch) from the target worktree. No fetch needed, the commit is already there
• Changes on a remote: run the pull in the other worktree without leaving yours: git -C ../integration pull. Wrap it in an alias if you do it often (e.g., wtp = "!f() { git -C \"../$1\" pull; }; f", then git wtp integration)

The best advice in the thread is the one people resist the most: just commit. Commits aren't only for working code. A throwaway WIP commit can be cherry-picked, rebased, squashed or undone with git reset later. Uncommitted changes can't do any of that. Git gives you way more options once something is committed.

This matters even more with AI agents. When three agents each work in their own worktree, "commit early, cherry-pick what works" is a much cleaner way to combine their output than shuffling patch files around.

References

• Stack Overflow, "Does git worktree allow 'pulling' from a different worktree?" (2023): https://stackoverflow.com/questions/76961918/does-git-worktree-allow-pulling-from-a-different-worktree
• https://git-scm.com/docs/git-worktree

Related

• Git Worktree
• Git

About Sébastien

Ready to get to the next level?