introducing built-in Git work tree

support for claude code. Now agents can

run in parallel without interfering with

one another. Each agent gets its own

work tree and can work independently.

Now this is really really sweet and I'm

kind of excited to show you my first

impressions, my first time trying this

and the thoughts I immediately have as

soon as I see this post. I've known

about work trees for many many years but

rarely actually ever use them. Probably

quite similar to you but I've never

actually taken the leap to integrate it

with clawed code. So having it built in

in theory just makes it super duper

easy. So let's test it out and see

what's going on with it. So I am now

inside my main work repo which is my

course video manager. And inside here

I'm going to run git status. And you can

see here I'm on my main branch. Now I'm

going to run a second command which is

get workree add UI updates. And when I

run this and we can see actually inside

the explorer here that a new folder has

been created called UI updates. And now

if we cd into there, if we see cd UI

updates inside here and run git status,

we can see it's on a branch called UI

updates. So this new folder has a

separate git state essentially like it

can be on a separate branch from the

main branch. Now inside this UI updates

folder, I'm going to call touch fooar.md

here and create a new file called

fooar.md. And one thing you'll notice is

if you're inside VS Code or probably

cursor too, is that inside your source

control panel, you now have the main

repo for the course video manager,

that's the main branch. And then this

one, you actually see your work tree

too. And we can see that there are some

changes inside the UI updates. I can

then stage this and actually commit it

to the UI updates branch. New fooar.md

inside here with VS Code. Of course, I

can publish the branch up here and even

make a PR to the original branch all

within this same nice UI and without

ever leaving my IDE. Once I'm done with

this, I can then just Okay, maybe we

merge this pull request. That looks

really nice. Now, I can open up source

control again and I can refresh inside

here and attempt to pull down any

changes. So, if I go I'll just cd back

into the main directory. I'll go get

pull and I should now have a fooar

inside my actual main directory which is

just

where's it gone? Where's it gone?

Where's it gone? There it is. fooar.md

inside the main branch of my repo. Now

that I'm done with that work tree, I can

either simply remove it just by running

uh rimf UI updates or I can run git

workree remove UI updates as well. I'm

fairly sure that does kind of the same

thing. Now, if we go back in and we look

inside the source control again, we now

just have a single um work tree

available, which is our main work tree.

So, work trees are a super convenient

way that you can have multiple branches

of something checked out on your machine

at once. And the tooling in your IDE, if

it's good, like VS Code is, will pick it

up and allow you to modify them

independently or of course you can do it

from the terminal as we were doing

there. So, let's now test out the clawed

version of this where we're going to run

clawed

workree like this. Now what this does is

it creates the work tree

atclaude/worktrees

cheerful coalescing worth. So it has

created the the work tree with a kind of

random funny name. Here we can see the

work tree in the same way that we did

before. So it's just using git work tree

under the hood. And now inside here we

can actually tell it uh delete the

fooar.md file. It's now searching for

the file and it's going to run remove on

it to get rid of it. fubar.mmd has been

deleted which we can see on the work

tree. That's very nice. Commit this.

That looks good. Again, it's doing some

git status, doing some git log. It's

adding the file, then committing the

file, and then I'm going to push it up

and make another PR to remove it.

Though, to be honest, you can kind of

see by now that Claude is really just

doing the same setup as we had before.

It's just automatically naming you a

branch and things like that. When I quit

out of here, so let's say I do Ctrl + C

a couple of times, I then get the option

to keep or remove the work tree. If I

remove the work tree and I haven't

pushed my work, then all of my changes

or my commit history will be lost. But

instead, I'm actually going to push this

up. So, it's going to actually push up

the work. And then I should get the

option to let's say let's say I'll

remove the work tree for now. That makes

sense. Okay, I've just had my first

paper cut with this actually, which is

it's not behaving how I expected on the

branch. It seems that when it created

the work tree, it actually made the

commit against main. Look, if I run get

status here, you can see we're on main.

And then when I run git log, you can see

the commit in the history where it

deleted fooar on main. So it seems like

git work tree doesn't behave in quite

the same way as the clawed work tree

does because on clawed hyphen work tree,

it seems like I might have to specify

something else in order to get it to

work on a separate branch. Okay, I've

just been doing some more experiments

here and hopefully I've landed on a

solution or at least I understand more

what's going on. Now I started a new

session and I said add a new file called

fubar.mmd. Commit it and push it to the

branch. It wrote the file. It then did

some git status. We can see it's on a

branch work tree delightful dazzling

sketch and the branch is up to date with

origin main. So it looks like the source

of the branch or at least sort of what

it thinks it is is main even though

we're on a different work tree. People

who understand work trees better than I

do probably can understand this uh more

than I can. But that's what I'm seeing

at least. It then get added and get

committed and it attempted to get push.

I have a safety hook that blocked the

push here, but it gave me a command to

run. It said, should I proceed with git

push origin workree delightful dazzling

sketch. I then ran this. So, I ran git

push origin work tree delightful

dazzling sketch. And it created a new

branch here with that name. So, this is

a really important thing. If you're

using claude work trees, your agent

needs to push with a specific uh name

branch. Otherwise, by default, it's

going to be the one that it created the

work tree from. in this case main. To

put that another way, if your main

branch is not protected and you create a

work tree from it, you might end up

accidentally pushing commits to main

when you wanted to push them to a

separate branch. Either way, this is

fine and something you can probably

prompt for as well. So, I don't hate it.

Overall, I really like the way that git

work trees are like totally managed by

Claude here. It means that the life

cycle of each work tree can be tied down

to a single agent and its work, which is

very, very appealing. I'm not sure why

you wouldn't want to use git work trees

like every single time you use claude

because it just means that you can

guarantee that every single time you

have an idea or you want to do something

you can just like instantly ping up a

new work tree get things working and

just like ping that back to main as a

PR. It basically makes parallelization a

lot more free than it was before which I

really like. Another thing I'm intrigued

by from the announcement is the fact

that sub agents now support work trees

as well. So you can just very simply

spin up a sub agent, get it to make a PR

back to main and just have that kind of

orchestrated from above, which just

seems really really nice. Though it does

seem like something you have to opt into

to say ask claw to use work trees for

its agents. It won't do this

automatically. It seems like I'm really

really excited to try this and work with

this more. And I think it's just going

to offer so many free parallelization

opportunities. And I just love it when a

tool kind of absorbs the complexity of

another tool into itself and helps you

manage its life cycle. That's great.

Love all that. Right now, I'm working on

a Claude Code course, which the landing

page and the price and stuff and all of

the syllabus is going to come up pretty

soon. And this is definitely going to be

on it. I really believe that AI coding

is not that different from human coding.

It's just that you need to be a lot more

aware of the constraints and you need to

be able to teach the AI about all the

fundamentals that we've known for 30

years. And so the course is going to be

about reintroducing those fundamentals

like TDD, like uh effective

parallelization, like planning in a

decent way where you get feedback

quickly, all of that stuff and just

taking that into the AI era. So thanks

for following along and I will see you

very soon. Anyway, if you like the sound

of all that, I talk about all that on my

newsletter as well, which is free, which

is great obviously, and you can find

that at the link below.