Git Worktree is a powerful but often underrated tool in Git’s arsenal that lets you work on multiple branches simultaneously in the same repository without switching between them. If you have ever faced a situation when you need to quickly fix a bug in the seller, simultaneously developing a new feature and not losing uncommitted changes, then Worktree will be your salvation.

## Why do you need Git Worktree?

Imagine: you are working on a big feature in the feature/new-ui branch, but suddenly there is an urgent hotfix for the main main branch. Without Worktree, you would have to commit or stash changes, switch to main, create a new branch, fix a bug, and then come back. Not only is it time-consuming, it also risks breaking your current progress. Git Worktree solves this problem by allowing the creation of separate "work trees" - independent directories for each branch.

Here are the key benefits:

• Parallel work on tasks: You can keep main branches open for stable version, feature/new-feature for new functionality and hotfix/bug-fix for urgent fixes. There is no need for constant git checkout, which can conflict with your changes.

• Risk Minimization: Forget about accidentally losing files when switching branches. Each Worktree has its own index (staging area) and HEAD, so changes in one directory do not affect the others.

• Convenience for review and testing: With a Pull Request review, you can clone a colleague’s branch into a separate Worktree, play a bug, or test changes without interfering with your main job. This is especially useful in teams where you need to quickly check the code without fully cloning the repository.

• Long process support: If one branch runs long-term tests, builds, or even a server for local testing (like Docker), you can continue to code in another Worktree. There is no downtime – everything works in parallel.

• Saving space and time: Since all Worktree share the same repository (objects, commit history), you are not wasting disk space on multiple full clones. This is ideal for large projects with gigabytes of data.

Hint: If your project includes CI/CD, Worktree will help you test different versions of the code locally, without having to make changes to the remote repository for each test.

## How does Git Worktree work?

Git Worktree is an extension of the standard Git model, where a repository can have multiple working trees. The main repository remains the same, but each Worktree is like a separate copy of the working directory.

• Shared elements: All Worktree use the same Git database (.git folder with objects, refs and history). Commits, branches and tags are synchronized between them.

• Individual Elements: Each Worktree has:

  • Your working directory (directory with files).
  • Your HEAD (pointer to the current commit or branch).
  • Your index (staging area for changes).

• Blocking Branches: Git does not allow checkouts to run on multiple Worktrees at the same time. This prevents conflict. If a branch is occupied in one Worktree, you will get an error when you try to use it in another. However, you can work with different commits or create new branches.

• Remove and clean: Remove Worktree does not affect the branch or commits – they remain in the repository. But if Worktree was deleted incorrectly (for example, manually deleted a folder), use git worktree prune to clean up service records.

Example scenario: Let’s say you have a repository in /project. You create Worktree in /project-hotfix. Now you have two directories: the main one on main and the second one on hotfix/bug. The commit in /project-hotfix is immediately visible in the main repository, but the files in the directories are independent.

Hint: If you use an IDE like VS Code, open each Worktree in a separate window. This will allow you to work in parallel with different settings (for example, different extensions or terminals).

## Basic teams and workflow

Let’s break down the basic workflow with examples. Suppose your repository is in /Users/user/my-repo and you want to create a Worktree for hotfix.

1. Creating a new Worktree:
   bash copy

Create a new Worktree with a new hotfix/timeout branch from main in the directory ../my-repo-hotfix

git worktree add../my-repo-hotfix -b hotfix/timeout main

This will create a new `../my-repo-hotfix` directory, checkout will not include the `hotfix/timeout` branch created by `main`.

Hint: If the branch already exists, drop `-b`: `git worktree add ../my-repo-feature feature/existing-branch`.

2. ** View all Worktree:**
```bash
git worktree list

The conclusion might look like this:

/Users/user/my-repo        main [main]
/Users/user/my-repo-hotfix  hotfix/timeout [hotfix/timeout]

This shows the path, the current branch and the HEAD.

3. ** Worktree removal:**
   bash copy

   git worktree remove ../my-repo-hotfix

Make sure that there are no uncommitted changes to the directory, otherwise Git will refuse to delete.

4. ** Clearance of official data:**
   bash copy

   git worktree prune

Useful after manually removing directories or for deleting links to non-existent Worktree.

Example of a full cycle:

• You're basically repositories on main.
• Create a Worktree for the feature: git worktree add ../feature-branch -b feature/new-ui develop.
• Go to ../feature-branch, make changes, commit.
• You go back to the main, you see the commits, but the files haven't changed.
• Upon completion: git worktree remove ../feature-branch.

Hint: Use scripts for automation. For example, a bash script for creating Worktree using a template: create_worktree.sh branch_name path from_branch.

## How to Integrate Worktree into Your Process (with Examples for Codex App)

If you use an AI assistant like Codex App, you can ask it to automate the creation of Worktree. The request format is simple and structured to avoid errors.

Recommended request format:

• ** What to create: ** New branch or existing branch.
• **From main, develop, a specific commit (e.g., abc123) or a tag.
• **The path to a new directory (absolute or relative).

Examples of requests for Codex App:

"Create worktree in `/Users/alexey/my-repo-hotfix`, `hotfix/timeout` branch from `main`." (Creating a new branch from main.)
Do worktree for the existing `feature/bot-menu` branch in the adjacent `./sibling-folder` folder. (Uses an existing branch without -b.)
- "Show all worktree and remove unused ones." (Calls list and prune.)
Create a worktree from the `f1a2b3` committ to `/temp/debug`, without creating a new branch. (To debug a particular state.)

Hint: If your workflow follows Git Flow (feature/hotfix/release), I recommend the scheme:

• Main Worktree: main or develop for everyday work.
• Feature-Worktree: In ./features/<feature-name> for new features.
• Hotfix-Worktree: In ./hotfixes/<issue-id> for urgent fixes.
• Release-Worktree: In ./releases/<version> to prepare releases.

This will keep everything organized. In the Codex App, you can say, "Propose a worktree scheme for Git Flow in my project."

## Conclusion and advice

Git Worktree is a tool that greatly simplifies life in multitasking projects. It saves time, reduces risks and makes development more flexible. Start with simple experiments in the test repository to master the commands. If you work as a team, share this article – perhaps Worktree will become the standard for your workflow.

Additional advice:

• Avoid too many Worktrees (more than 5-10) to avoid getting confused.
• Use git worktree lock to protect against accidental removal.
• For advanced users: Integrate with tools like fzf to quickly find Worktree.
• If errors occur (e.g., “working tree is dirty”), always commit or stash changes before creating. u