Up until now, we've been running Ralph directly on our main branch, which works , but it's also kind of annoying. Because the moment Ralph starts running, our product is basically locked. If we start editing files or switch branches, we interfere with the running loop. Instead of running Ralph on our main branch, let's give the agent their own dedicated workspace to work in. And we'll cover two clean ways to achieve this, and the first way is going to be

to work in. And we'll cover two clean ways to achieve this, and the first way is going to be a git work tree. In essence, a git work tree lets you check out the same repository into a separate folder with its own branch. Setting this up is pretty easy. Inside our project, we can say git work tree at -b to create a branch in line. Let's call it my feature. And let's say the directory is going to be view shop my feature. And now when we see D into that directory, we can see we

is going to be view shop my feature. And now when we see D into that directory, we can see we essentially checked out a fresh branch called my feature. This checked out branch shares its git history with our main folder. So git operations are pretty straightforward. Let's run this project by saying our in-depth, and we'll be presented with an error because vit is not installed. And this is because files that are not tracked by git, like dependencies or .n files, don't get

this is because files that are not tracked by git, like dependencies or .n files, don't get initialized automatically. So in this case, we need to bootstrap our project by saying yarn install, and now we can run your in-depth. Instead of bootstrapping or work trees manually, we can install a post checkout hook, and we can obviously ask Claude for this. Install a post checkout hook that installs node modules. If it's not there, using your right. And if we take a look at the post checkout hook, it's basically just a

using your right. And if we take a look at the post checkout hook, it's basically just a shell script that is going to check if node modules is there. And if it isn't, we're going to run yarn install. Let's check if this works. Let's go back to our main directory. Let's say git work tree list. We can see our my feature branch, we can say git work tree remove view shop my feature. There we go. Let's remove our branch as well. We can say git branch D my

feature. There we go. Let's remove our branch as well. We can say git branch D my feature. And now we can recreate our work tree by saying git work tree add will recreate the branch and will re-initialize the work tree. And as you can see here, because we have a post checkout hook installed, our node modules will be installed. Now, if we go to the work tree, and we can verify our node modules is there and yarn death will work. So that's pretty cool. A bigger challenge when

our node modules is there and yarn death will work. So that's pretty cool. A bigger challenge when working with a project that uses feet is the port assignment, because the first time we run yarn death, we get port five on seven three, as you can see here. But if we were to go to our main branch, I will say yarn death, look at a different port. In this case, port five on seven four. And while this allows us to test both branches at the same time in the browser, it makes it very hard to

And while this allows us to test both branches at the same time in the browser, it makes it very hard to know which port maps to which branch. And that's where port list comes in. We can install this by saying npm install g portless. To run portless from our main branch, we can say portless, run yarn death, and we have to expose it on the network. And then we get this stable URL we can visit in the browser. If you now run portless from our work tree, portless will detect it's a work

the browser. If you now run portless from our work tree, portless will detect it's a work tree, and it will create a subdomain automatically for us called my feature, which is the name of the branch. And we can visit this in the browser. And this makes it very easy to visually see which branch we are testing. All right, let's clean up our work tree again. Let's say our RF view shop, my feature. And now let's go into our main branch. And we can say get work tree

view shop, my feature. And now let's go into our main branch. And we can say get work tree list. And even though we deleted the directory, it's still going to be listed as a work tree. It's listed as printable. So we can say get work tree run. And now it's going to be cleaned up . Finally, let's also clean up our branch. Cloud nowadays has a built in way to create work trees as well. We can say cloud - work tree. And we can give it a name, for example, my

work trees as well. We can say cloud - work tree. And we can give it a name, for example, my feature. And this will set up a new work tree inside the cloud work trees directory. And we named it my feature. And if you want, we can customize the path by using the work tree create and the work tree remove hook. Personally, I really like the work tree flag when working interact ively with cloud. But for running Ralph loops, I think we need a bit more control. And that's why

ively with cloud. But for running Ralph loops, I think we need a bit more control. And that's why I added the flag to a Ralph CLI to control the workspace handling. And I also took the liberty of extending our Ralph CLI with a small configuration file, which is called Ralph dot Tomo. And as we can see here, our workspace mode is configured to be work tree, or directory is going to be this lowercase directory. And I also like to use Yolo box. So I set that to true. So now when we run

this lowercase directory. And I also like to use Yolo box. So I set that to true. So now when we run Ralph, a press C to select a PRD. Let's choose card coupon. We'll see the workspace will be created as a work tree inside this directory. And if you verify, we can see the work tree is created here. And while Ralph is doing its thing, let's talk about the second way we can use to manage our agent workspaces. And that is the copy on right. The biggest disadvantage of a work tree, in my

our agent workspaces. And that is the copy on right. The biggest disadvantage of a work tree, in my opinion, is the fact that it takes up a lot of disk space. If we have five work trees, that means we have five additional copies of node modules on our file system taking up space copy on right is a file system feature that creates something that looks like a full copy of your directory. But the files aren't actually duplicated. Instead, the file system creates a pointer to the

directory. But the files aren't actually duplicated. Instead, the file system creates a pointer to the underlying data and keeps track of modifications you make. And only when a modification occurs, it will create an actual copy of the modified file. Copy and write is available on all Mac OS systems with EPFS and Linux systems with BTRFS as well. If you're on Windows, your best bet is to stick with the work trees. To create a copy on right on a Mac, we can say CP dash R

is to stick with the work trees. To create a copy on right on a Mac, we can say CP dash R with the capital dash C will say few shop and we'll copy it into view shop cow. This new directory shares exactly the same underlying data as the original one. And only when we modify a file, the copy gets created and starts taking up disk space. This also means you don't need post checkout hooks to reinstall the dependencies and nor do you need to copy environment files because the copy

hooks to reinstall the dependencies and nor do you need to copy environment files because the copy will already contain them. If you go into the directory, we can see our node modules directory is already there. This makes setting up an agent workspace super fast because we don't need to pull in any dependencies. And this is actually how I like to run my relflups. The trade off here is that you no longer have a shared git workspace like with work trees. But if you use pull

here is that you no longer have a shared git workspace like with work trees. But if you use pull requests on GitHub, this is not a big deal. Let's clean up our directory. Let's go into our original one. And let's modify our Ralph configuration file. And instead of saying work tree, we can say copy on right. Now when we run Ralph, we press C and let's spawn our second PRD. We can see the workspace gets created in this directory and it's going to be a copy on right. And again,

see the workspace gets created in this directory and it's going to be a copy on right. And again, if you take a look at this directory, we can see that the node modules are there as expected. Let 's meet back when the two PRDs are completed. All right, both PRDs are complete and I started a dev server so we can quickly take a look a small note when using portless. And we have a copy on right directory, which is this one. It doesn't detect it's a work tree because it isn't a work

right directory, which is this one. It doesn't detect it's a work tree because it isn't a work tree and you lose out on the automatic subdomain handling. But you can override the name of the project by just saying portless view shop persistent card, yarn dev with the host flag. So let's first test the coupon where we add something to the cart. We see a nice coupon field here and we should be able to enter Friday for 50% off. And this looks great. Next, let's look at the second

should be able to enter Friday for 50% off. And this looks great. Next, let's look at the second feature, the cart persistence. If we add something to the cart and we refresh the browser, the cart will stay persisted. And this is looking great. Finally, let's merge both features in our main branch by saying merge the name of our branch into main and the name of our second branch. I'm reading this in YOLO box so we can bypass permission safely. All right, and all seems to have

reading this in YOLO box so we can bypass permission safely. All right, and all seems to have gone well, we merged, we had a small conflict. So let's quickly test if everything still works. So when we add something to the cart and we refresh, it's going to be persistent, which is great. And now let's see if the coupon is there, Friday, and we get 50 % off and everything seems to work, which is great. In the next lesson, we'll take a look at how we

% off and everything seems to work, which is great. In the next lesson, we'll take a look at how we can manage our PRDs better. Join me there!