I'm using claude --worktree for everything now

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.