LongCut logo

Devs can no longer avoid learning Git worktree

By Joshua Morony

Summary

Topics Covered

  • Worktrees Mimic Multi-Developer File Systems
  • Git Worktrees Enable Parallel AI-Human Coding
  • Worktrees Allow Simultaneous Branch Checkouts
  • Agents Auto-Create Worktrees for Unhindered Workflow

Full Transcript

I've been fortunate enough to be able to collaborate with and generally just hang out on Discord with a particularly talented and productive software engineer over the past few years. This

person, Chiao Tran, for those of you who may know him from his open source work, has helped shaped a lot of my workflow over the years. In general, if I see Chiao doing something, I can be

reasonably sure I should probably be doing that as well. One of those things, something that came up many times, but I kept putting off bothering to learn, was git work trees. It sounded hard and

generally I could avoid the scenarios where it seemed like they were most useful. Generally, when you suddenly

useful. Generally, when you suddenly need to context switch away from whatever you are working on to do something else in the codebase, maybe some kind of hot fix situation or

reviewing a PR. I would generally just try to avoid those situations by attempting to get my code to a point where I could make a clean commit or worst case scenario I could just stash

the changes. But work trees are actually

the changes. But work trees are actually pretty simple both conceptually and to use. Think of one of the main purposes

use. Think of one of the main purposes of Git. It enables multiple developers

of Git. It enables multiple developers working on different file systems to collaborate on code. You could be working on one feature on your machine and file system. Another developer could

be working on another feature on their machine and file system. And when you're both done, you smash those features together and you have one unified codebase. To understand the problem git

codebase. To understand the problem git work trees address, let's focus on the problem AI creates. One that is much less avoidable than the other situations

I outlined. The problem, or at least a

I outlined. The problem, or at least a problem, arises when you're using some kind of agentic AI process that is going to be working on a task for any

non-trivial amount of time. Take my

current agentic AI workflow for example.

My general process is that I design a track which outlines work to be done in phases. I then trigger my script which

phases. I then trigger my script which will launch a new AI agent to tackle each phase in succession until the track is complete. and then a PR is opened by

is complete. and then a PR is opened by the agents for me to review. So, feel

free to drop a comment and subscribe if you're interested in me diving into this workflow more. It's more or less the

workflow more. It's more or less the same Ralph approach a lot of people have been using lately, but I've been using it to build out a lot of complex features and have been having great success with it. But for this video,

let's just focus on the problem git work solve. The problem is that these AI

solve. The problem is that these AI agents are using your file system and you want to use your file system, too. I

get my Ralph agents to start executing on a task that is going to take 15 minutes, 30 minutes, an hour maybe, and I just what? Watch YouTube for a bit

until the PR is ready to review. Not a

bad option, certainly, but not the most productive one. Likely, I'm also going

productive one. Likely, I'm also going to want to work within that same code base on something else. But I can't really because the AI agents are making edits to the same code base on the same

file system at the same time. To deal

with this, we can quite simply create a git work tree. You can run this command to create a work tree manually, but personally I use lazy git and other tools would support this as well. I can

just come in here and create a new work tree based off of main. And what this is going to do basically is create a copy of the project file somewhere else on

your file system. But both instances of those files will share the same git tracking. So I have my main repo called

tracking. So I have my main repo called games and I have a sibling directory called games work trees and that is where I want to create this work tree.

And then we can supply a name for the branch we will be working on. Keep in

mind that you can't have the same branch checked out in a work tree that you also have checked out in your main project folder. I can make changes from within

folder. I can make changes from within my main project folder and I can make changes within my work tree folder.

These two folders can work entirely independently. And when I am done with

independently. And when I am done with the work tree, I can easily just merge the branch from the work tree into the main repo just as if it were a normal

branch. To think of it most simply, work

branch. To think of it most simply, work trees allow you to have different branches checked out at the same time on the same file system. And rather than bothering to create these work trees

myself to deal with the AI problem, I've just got it incorporated as part of my agentic AI workflow. Whenever agents

begin work on a new track, they will first create a work tree and branch for it. And they will only work within that

it. And they will only work within that work tree, which means I am then free to work on the main codebase as I please, and I can just review and merge the PR from the work tree when I am ready. One

situation that comes up a lot in this workflow is that I will want to check out the branch the agents are working on to test or review it. But if a work tree has a branch checked out, you can't

actually check out that same branch. But

you can check out a commit in a detached readonly state. So instead of checking

readonly state. So instead of checking out the branch itself, you can instead just check out the latest commit from that branch. So you can still easily

that branch. So you can still easily take a look at work tree branches from within the main project directory if you want. Alternatively, especially if you

want. Alternatively, especially if you wanted to make some manual changes, you could also just switch into working in the workree folder directly. If you

found this video useful, a like or subscribe before you go would be greatly appreciated.

Loading...

Loading video analysis...