Git worktrees

Git worktrees.md

Git worktrees and Git branches are related but fundamentally different in how they let you interact with your code. Both are part of Git, but they solve different workflow challenges.[2][5]

What Are Branches?

Branches are Git's way of diverging from the main line of development to work on different features or fixes. In standard Git branching, you work in a single working directory and switch between branches using commands like git checkout or git switch. When you switch branches, Git updates the files in your current directory to match the branch you're switching to. This means you need to either commit or stash your work-in-progress changes before switching, which can disrupt your workflow.[1][5][2]

What Are Worktrees?

Git worktrees allow you to check out multiple branches from the same repository simultaneously, each in its own separate working directory. Instead of switching branches by changing what's checked out in one directory, you switch branches by literally moving between different directories on your filesystem. The branches themselves still live in the repository—worktrees just provide multiple physical workspaces that all connect to the same underlying Git repository.[3][6][1][2]

Key Differences

The main difference is physical separation. With branches alone, you have one working directory that shows different content when you switch branches. With worktrees, each branch gets its own dedicated directory, so all branches can be checked out and visible at the same time. This eliminates the need to stash or commit work-in-progress changes when you need to switch contexts.[5][2][3]

For example, if you're working on a feature and your boss asks you to fix an urgent bug, with traditional branching you'd need to stash your changes, switch branches, fix the bug, commit it, then switch back and unstash. With worktrees, you simply navigate to a different directory where a different branch is already checked out, fix the bug there, and return to your feature work without any stashing.[6][8][5]

Practical Benefits

Worktrees enable true parallel development—you can have your IDE open to one branch while running tests in another branch simultaneously. This is particularly valuable when working with AI coding assistants like Cline, where you might want multiple LLMs working on different branches at the same time without interference. Each worktree is completely isolated, preventing conflicts and making experimentation safer.[7][9][2]

The command to create a worktree is straightforward: git worktree add <path> <branch-name>. This creates a new directory at the specified path with the branch checked out. You can list all worktrees with git worktree list and remove them with git worktree prune after deleting the directory.[2][6]

Trade-offs

Worktrees do use more disk space since each one is a full checkout of the repository. They can also introduce complexity for Git beginners who need to understand that they're managing multiple directories connected to the same repository. However, for developers working on multiple features simultaneously or needing to frequently switch contexts, worktrees eliminate the friction of constant branch switching.[8][7][2]

1 2 3 4 5 6 7 8 9

You're misunderstanding the workflow slightly—you don't merge all three branches into main in separate folders. Instead, you review all three implementations side-by-side, choose the best approach or cherry-pick the best parts, and create one final implementation that goes to main. Here's the step-by-step process:[1][2][3]

Step 1: Create Three Branches with Worktrees

Start from your main branch and create three separate worktrees, each with its own branch:[2][1]

git worktree add ../feature-claude feature-claude
git worktree add ../feature-gpt feature-gpt  
git worktree add ../feature-gemini feature-gemini

This creates three separate directories (one level up from your main repo) with three separate branches. Each directory is a fully functional working directory where you can make changes independently.[1][2]

Step 2: Work in Parallel

Open three instances of your IDE or Cline, one in each directory. Let each AI work on the same feature in its respective branch. They'll all create commits independently without interfering with each other. You now have three completely separate implementations of the same feature.[3][2]

Step 3: Compare the Implementations

Once all three are done, you need to compare them, not merge them all. You can do this several ways:[4][5]

Option A: Open all three directories side-by-side in your editor and manually review the code differences.[3]

Option B: Use Git diff to compare branches:[5][4]

git diff feature-claude feature-gpt
git diff feature-gpt feature-gemini

Option C: Use a visual diff tool like Beyond Compare or Meld to see file-by-file differences.[5]

Step 4: Create the Final Implementation

Now comes the human decision-making part. You have three options:[3]

Option A - Pick One Winner: If one implementation is clearly superior, merge just that branch into main:[6]

git checkout main
git merge feature-claude

Option B - Cherry-Pick Best Parts: Create a new branch and manually combine the best code from all three. Copy functions from one, error handling from another, architecture from the third.[3]

Option C - Guide AI with Examples: If Cline got stuck on feature-claude, show it the code from feature-gpt or feature-gemini as reference. Let it create an improved version based on seeing the alternatives.[3]

Step 5: Clean Up

Once you've merged your final version to main, delete the experimental branches and remove the worktrees:[7][2][1]

git worktree remove ../feature-claude
git worktree remove ../feature-gpt
git worktree remove ../feature-gemini
git branch -d feature-claude feature-gpt feature-gemini

The key insight is that the three branches are experiments, not three features you're trying to preserve separately. You're using parallel exploration to find the best solution, then consolidating into one final implementation that goes to main.[3]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

You're absolutely right—you can just clone three times and checkout different branches in each, and it would functionally accomplish the same thing. But worktrees have several key advantages that make them better for this workflow.[1][2][3][4][5]

Disk Space Savings

When you clone three times, you get three complete copies of the entire Git history—three .git folders with all the objects, refs, and metadata. For a large repository, that's significant disk space duplication. With worktrees, you have one .git folder shared by all three working directories. Only the actual working files are duplicated, which is much smaller.[2][4][5][6]

Shared Repository State

With worktrees, all three directories share the same repository, which has practical benefits:[7][2]

• When you git fetch in one worktree, all worktrees instantly see the updated remote branches[2][7]
• You can easily reference branches across worktrees without setting up complicated remote configurations[7]
• Commands like git diff feature-claude feature-gpt work seamlessly from any worktree[7]

With three separate clones, each has its own "origin," and comparing branches across clones requires setting up cross-remotes or pushing to a central repo first. It's more cumbersome.[7]

Easier Management

Worktrees know about each other. Run git worktree list from any worktree and you see all of them. If you have three separate clones scattered across your filesystem, nothing tracks them—you might forget where you put one or lose track of work in progress.[2][7]

Git also enforces that a branch can only be checked out in one worktree at a time, preventing accidental conflicts. With separate clones, you could accidentally checkout the same branch in multiple places and create confusing situations when pushing.[2]

When Cloning Makes Sense

That said, multiple clones aren't wrong—they're just less efficient. If you prefer the mental model of completely independent repositories, or if you're already comfortable managing multiple clones, go for it. The functional outcome is similar. But for the parallel AI development workflow you're describing, worktrees are the cleaner, more space-efficient approach that keeps everything organized in one logical repository.[3][4][5][1][7]

1
2
3
4
5
6
7
8
9
10