Developer Tips Vol II - Git Worktrees

Haven’t source control systems changed so much over the years? From the early days of just storing flat files on some server to Visual SourceSafe and a bunch of others that have come and gone.

Git is the tool of choice for most developers today, started in 2005 and the exploding in popularity thanks to platforms like GitHub, this tool has it all - local/remote repositories, cloning, branching, merging, you name it.

With the emergence of using AI assisted code development tools, the features of git really started to shine. I would typically

• Create a feature/fix/whatever branch off the dev branch
• Run an AI agent and work with it to develop whatever it is I’m working on
• Use the diff to check the code changes manually and make any modifications.
• Do whatever is necessary to finish the job - test, pass commit hooks, etc
• Merge/Rebase back to dev
• Rinse and repeat.

While you can get the AI agents to handle the git part for you, I like this workflow as a guard step to make sure i’m happy, and if i’m not it’s easy to revert or just trash the whole branch.

This has been working well for me, and my productivity has skyrocketed.

However, this approach started to show a small crack - you can only have one branch checked out at a time, which if you know git, can be a bit of a hassle if your workflow requires you to change branches frequently.

What is a git worktree?

git worktress solves this problem - they let you check out multiple branches of the same repository at the same time, each in its own directory, all sharing the same .git history and object store.

Think of it as:

• multiple clones
• without duplicated data
• without reinstalling dependencies
• without losing your place on your main branch

You get parallel working directories, but only one underlying repo.

This can work really well with an AI assisted workflow because they are great for:

• Long‑running training jobs
• Experiment branches
• Quick hotfixes
• Heavy repos (PyTorch forks, LLaMA variants, etc.)
• Environments that take ages to rebuild

Worktrees let you do all of this without interrupting anything else.

For example, let’s say you’re training a model on experiment/rlhf-v3, but the training will run for 6 hours.

Suddenly you need to fix a production bug on main.

Using my normal workflow, this would mean I would have to:

• stash or commit
• switch branches
• interrupt training
• or clone the repo again

With worktrees:

• training continues untouched
• you create a new worktree for main
• fix the bug
• push
• carry on

Cool right?

how do worktrees work in practice?

A repo has one .git directory - the object store.

Worktrees create additional working directories that all point to that same store.

To create an new worktree

git worktree add ../my-feature feature-branch

This gives you:

repo/ repo/.git my-feature/ <-- new folder with its own checkout

Both folders share the same Git history and objects.

Common workflow you will actually use?

1. Work on multiple branches simultaneously

git worktree add ../bugfix bugfix/urgent git worktree add ../experiment experiment/new-loss-fn

Each folder is its own isolated workspace.

2. Run long jobs without blocking your main workspace

Perfect for:

• model training
• data preprocessing
• evaluation scripts

You can leave a worktree running a job and keep coding in another.

3. Keep a clean main workspace

A common setup:

repo/ --> main branch repo-exp/ --> experiments repo-fix/ --> hotfixes

No more stashing. No more dirty working trees.

4. Avoid massive re-clones

Large AI repos can be tens of GB.

Worktrees reuse the same object store, so they’re instant and lightweight.

Things to watch out for

You can’t check out the same branch twice - git prevents this to avoid conflicts.

Don’t manually delete worktree folders. Instead, use:

git worktree remove ../experiment

Branches aren’t deleted when you remove a worktree

The branch stays unless you delete it yourself.

Why this is great for AI assisted development

I asked Copilot why this is great for AI development, and I largely agree with the response

Worktrees give you:

• Parallelism - multiple branches active at once
• Isolation - experiments don’t pollute your main workspace
• Zero duplication - no extra clones
• Zero interruption - long jobs keep running

It’s the closest thing Git has to “virtual environments for branches”.

Final Thoughts

If you’re doing AI-assisted development, or even development over multiple branches at the same time or anything involving long‑running jobs, experiments, or large repos, Git worktrees are one of the simplest ways to split all of that up. They remove friction, reduce context switching, and let you work the way AI engineering is happening (or at least, that’s what I’m finding, YMMV) in parallel.