Speaker A
Today we're going to learn how to use Git work trees to start multiple agents that work at the same time on our project. Imagine we have a project and we have the main branch. Let's say it's an app and we want to have a different
Learn how to use Git worktrees with Codex CLI and Mac OS app to run multiple AI agents in parallel for redesigning projects efficiently.
Key Takeaways
- Git worktrees enable efficient parallel work by multiple AI agents on the same project repository without duplicating Git history.
- Worktrees save disk space and simplify branch management and merging locally, reducing dependency on remote GitHub operations.
- Codex CLI and Mac OS app both support managing worktrees and running parallel redesign tasks with AI agents.
- Multiple design styles can be developed simultaneously and merged selectively into the main branch.
- Worktrees provide a practical solution for concurrent feature development even when files overlap.
What the video covers
- Introduction to using Git worktrees to run multiple AI agents working simultaneously on different branches of a project.
- Comparison between copying project folders multiple times versus using Git worktrees that share a single Git repository.
- Explanation of how worktrees save space and allow branch sharing and merging locally without needing GitHub.
- Demonstration of setting up multiple worktrees for parallel redesigns of a web application using Codex CLI.
- Running multiple Codex agents in parallel with different design styles such as Swiss, futurism, brutalism, Bauhaus, Art Deco, and Japanese minimalism.
- Using Codex Mac OS app to manage worktrees and threads with similar concepts to the CLI but with a graphical interface.
- How to merge preferred redesign branches into the main branch locally and clean up worktrees after completion.
- Details on managing worktrees, including listing, renaming, and cleaning up unused worktrees.
- Discussion on practical scenarios where worktrees help when multiple features touch the same files.
- Final thoughts on the workflow benefits and alternatives like copying folders for isolated agent work.
Chapters
- 00:00Introduction to Git Worktrees and Multi-Agent Workflow
- 00:47Copying Folders vs Independent Git Repositories
- 01:22Advantages of Git Worktrees Over Folder Copies
- 02:13Setting Up Worktrees for YouTube Copilot Project
- 03:00Listing Worktrees and Branches
- 03:53Running Parallel Agents with Different Design Styles
- 04:39Using Codex Mac OS App for Worktree Management
- 05:48Creating and Managing Worktrees in Codex Mac OS App
- 07:48Worktree Cleanup and Final Merging Steps
- 09:15Summary and Alternative Workflows
Full Transcript — Download SRT & Markdown
Speaker A
design at the same time. Now we have AI agents and we can start like 10 different agents and we can prompt every AI agent to design the web page in a different style, and at the end we can
Speaker A
compare the 10 different versions. Now one way to do that is to get this folder that we have with the main branch and then copy it over 10 times. So we can literally copy the project folder four times and start an AI agent in every single
Speaker A
folder. With this setup, we basically have four independent directories and they point all to the same origin on GitHub. Let me rename the branches so that becomes a bit more clear. Say we have an application, we want to redesign
Speaker A
it. We have one folder with the main branch and we have four different independent Git repositories. We run three agents in parallel in those different folders. And once they are done with the redesign, we pick the design that we like. We push it to
Speaker A
GitHub and then we can make a pull request and merge it in the main branch.
Speaker A
So you see it gets a bit complicated. Now the alternative to that is using work trees. Work trees are very similar to this approach of copying folders.
Speaker A
Basically we also copy folders but they all share the same Git repository. So I'm going to copy this whole setup. I'm going to paste it because they are so similar. But at the same time the work trees don't have
Speaker A
their own Git directory. It's shared. And what that means is that all those folders use less space because they only have one Git directory. But more importantly, they can share branches or they can merge branches between each other. What does it mean? So imagine we
Speaker A
have a main branch and then we have those three branches air1, airb, and airc which are redesign one, redesign b, and redesign c. So if I'm in this folder, I can actually see all those three branches and then I can merge them in
Speaker A
main. I don't need GitHub actually. I don't need to push to GitHub and then pull anything that has created those work trees. And once we are done with the three versions with the parallel agents, we can pick one of the branches
Speaker A
that we like and just merge it into main. And I'm going to show you exactly how this works right now. We're going to open Codex CLI. We're going to start it in just a minute. But I want to tell you
Speaker A
this is YouTube Copilot, the project that we're going to be working on. And I'm going to create a new folder here that will hold all my work trees so I know where they are.
Speaker A
YouTube Copilot work trees. So these are the work trees that are going to be here and this is YouTube Copilot, the project. So in those three terminal windows I'll start Codex and I'll start agents in parallel that
Speaker A
are working on redesigning the web page. And on this fourth window I'll just open Codex and I'm going to tell Codex to create three work trees under YouTube Copilot work trees. Each work tree should switch to the following branches.
Speaker A
Let Codex work. I'm going to ask Codex to please start a local server so we can see the application that we're working with. You could also see the work trees here while the app is starting and I can
Speaker A
actually go to the repositories and do git worktree list. So we can see all the work trees and if we do git branch list you could see that every work tree can see every branch and this is the
Speaker A
application that we want to redesign. This is an application that I developed for myself for YouTube to generate me some thumbnails, tech backgrounds, and title improvers, analytics, and so on. So I'd like to redesign it and we'll start three agents in parallel. So we are
Speaker A
going to get three different versions of this design. Once we like one of the versions, we'll merge that into main.
Speaker A
I'm going to open Codex here, Codex here, and Codex here. And in every work tree I have told Codex to please redesign the front end according to Swiss international typographics, according to futurism, according to brutalism. So we're going to get three
Speaker A
different versions of this web application by three different agents working in parallel without interfering with each other. But the approach that you probably would need more in practice is, okay, I want to work on those two different features but they touch the
Speaker A
same file. How do I do that? You do that with work trees. I'm going to start them now. Start one, two, and actually I quickly interrupted this one because I started that in the wrong branch. So I'm going to start it here and going to go
Speaker A
to Codex and we watch them work. Now once they are done we're going to move to the Codex Mac OS app. We're going to check this out and once we're done with the Mac OS app we're going to
Speaker A
check out the approach with IDEs but they share a similar philosophy. And by the way the Mac OS app is synced with the CLI. So I can see this thread that I have started in the CLI now appear in
Speaker A
the Mac OS app. So they are all done. This is the original design and I have them here. So this is the futurism design that we have here. This is the brutalism design that we have and this is the Swiss style design that we have
Speaker A
which I think I like best but of course personal preference. Now what do we do from here? We can go back to Codex. Remember this is the folder where it all started, the YouTube Copilot. This is not a work tree. This is
Speaker A
the main folder. So we can go here and ask Codex to merge any of the branches that we have. In this case, I like the Swiss style most. So I can ask Codex, hey, merge with this branch. And since
Speaker A
they all share the same Git folder, the same Git history, I can merge them locally. I don't need to go through GitHub. So I can merge it here. Then I can ask Codex, hey, can you clean up the
Speaker A
work trees or remove the work trees? But this is how you work with work trees with the Codex CLI. I'm going to show you now how to do that with the Mac OS app because the controls there are a bit
Speaker A
different but the underlying concepts of course are the same. So I asked Codex, can you clean up all work trees and branches in this repo? Leave main.
Speaker A
That's my objective here. All right, the cleanup is complete. We have the YouTube Copilot project here again. We can open it in Finder.
Speaker A
We can open it in any text editor if we like. I can toggle the terminal here.
Speaker A
And now we're going to start three work trees again. We are going to start a new thread. And a new thread is just a space so I can talk to Codex the same like the terminals. And here instead of
Speaker A
local, I click new work tree. And it says create a copy of your local project to work in parallel. And this is exactly what we want. So I'm going to say redesign the front end according to Bauhaus modernism design style. We're
Speaker A
going to see here this icon which says this conversation is running in a local Git work tree. Now notice we didn't have to create any local folders. Codex took care of that. And if we open this work tree in Finder, so we're going to see
Speaker A
that it is being created somewhere under Codex work trees and then an ID and so on. So Codex takes care of creating those work trees and tracking them and so on. So we don't have to create those folders ourselves. We can open the terminal and
Speaker A
say git worktree list. We're going to see we have one work tree, but we would like to create two more. So I started a new thread then a new work tree and then I said please redesign the front end
Speaker A
according to Art Deco design style and start it on port 5173. I'm going to start it here. I can actually rename the work trees so it's a bit more intuitive Bauhaus style. I can also start a local project or a local thread which means
Speaker A
that we'll be in our main work tree where our main Git history which is YouTube Copilot. I'm just going to say here is a local thread so we can have it here in the sidebar and we're going to
Speaker A
ask Codex to design according to Japanese minim...
Speaker A
the concepts by the way we can also pin the threads like that and this important because of work tree cleanup work trees will never be cleaned up if a pin conversation is tied to it otherwise Work trees are eligible for cleanup when
Speaker A
it's more than 4 days old and you have more than 10 work trees. Although even if Codex cleans up the work tree, it will save a snapshot of the work on it.
Speaker A
So you can restore it at any point. So don't worry, Codex wouldn't just delete your work. But you can read more about work trees on their documentation. Now remember again our main branch is running on port 5171. This important
Speaker A
because now we'll actually merge the work from one of the work trees into main via the Mac OS app to see how that works. So this is the art deco style of the application and I think the others
Speaker A
are also done. The bow house is done on port 72. So this is the bow house design and the Japanese was also done on port 74. So those are the three different versions that we run in parallel. We're
Speaker A
going to pick one now. I think I like actually I don't like any of them but we're going to merge uh just for the demo we're going to pick this one the Japanese and in order to merge it we're
Speaker A
going to click here hand off to local what that would do is now give us an option to either create a local branch and all of this is local but local means the folder where we started the source
Speaker A
of truth for the git history so so basically this is what uh the Mac OS app means by local and we're going to click existing branch main and we're going to click checked out locally. It's already checked out means
Speaker A
our local folder is already on the main branch. We're going to click continue and we're going to say to local. So we're going to hand off changes to local and we're going to click apply and and we have handed off the Japanese
Speaker A
minimalism to our local space. Here we can see also the diff here and that's the Japanese minimalism that has been implemented here. We can also take the terminal and do get status. We can see the changes and we can now commit them
Speaker A
and so on. So if you go on the port 51 we can see that our application is not how it looked anymore. It's the Japanese minimalism style. Now we have two different work trees. We can either archive them or we can click branch from
Speaker A
here. This would create a new branch art deco style for example. We're going to commit and then we can keep working on this branch art deco style in the art deco style work tree. And we can also check out this branch in any other
Speaker A
thread as long as the work tree doesn't occupy it anymore. So any work tree, any local folder can check out any branch because the git history is shared as long as one branch is not shared at the same time by multiple work trees. So if
Speaker A
I switch to the local tree, I can't actually pick the art deco style because it's occupied. And if you work actually with IDs, you just need to find the folder of the work tree and then drag and drop it into your ID. For example, I
Speaker A
can drag and drop here into cursor and then you can start working in cursor on the work tree. If this is too overwhelming for you or if it seems too complicated, I think that's a fair point. In this case, you can just copy
Speaker A
and paste the folders. So, you can basically operate under this setup where you don't have to manage work tree. You can just have many folders. They don't share the git history. And I think that's good enough. I think it's another
Speaker A
useful way you can work with multiple agents. But if you prefer to just copy paste the folder and treat them separately, I think this workflow is also good enough.
Topics:Git worktreesCodex CLICodex Mac OS appmulti-agent workflowAI agentsparallel developmentbranch managementweb app redesignGit mergesoftware development workflow
![[YTP] Jordan Peterson: Rat King — Transcript](https://i.ytimg.com/vi/0qUoznGIe1M/maxresdefault.jpg)
![Nick & Charlie ‣ their story [+heartstopper forever] — Transcript](https://i.ytimg.com/vi/p4TiW1TZM3w/maxresdefault.jpg)
