# git worktree Command: Parallel Checkouts in CI

> git worktree manages multiple working trees from one repo. Reference for add, list, and remove to check out several refs in parallel without recloning in CI.

Source: https://latchkey.dev/learn/command-reference/git-worktree-command-reference  
Updated: 2026-06-26

git worktree attaches additional working trees to a single repository, each on its own ref.

A matrix CI job that needs two branches at once (for example to diff or build both) can use worktrees to avoid a second clone, sharing object storage between trees.

## Common flags

- `add <path> <ref>` - create a new working tree at path checked out to ref
- `add --detach <path> <commit>` - add a detached worktree at a commit
- `list` - show all working trees and their HEADs
- `remove <path>` - remove a worktree
- `prune` - clean up administrative records of deleted worktrees
- `--force` - override safety checks when adding or removing

## Example

```shell
# Build current branch and main side by side without recloning
git worktree add ../main-tree origin/main
( cd ../main-tree && make build )
git worktree remove ../main-tree
```

## In CI

Worktrees share the object database, so a second worktree is far cheaper than a second clone when a job needs two refs at once. Remember to git worktree remove (or prune) at the end so cached repos do not accumulate stale trees.

## Using this in CI

CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.

```.github/workflows/ci.yml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # history, tags, and git describe all need this

- run: |
    git rev-parse --is-shallow-repository   # expect false
    git rev-parse --abbrev-ref HEAD          # prints HEAD when detached
```

> `git rev-parse --abbrev-ref HEAD` returns the literal string `HEAD` on a detached checkout rather than a branch name. On GitHub Actions read `github.ref_name` instead; the git command cannot know what it was checked out for.

## FAQ

### git worktree Command: Parallel Checkouts in CI?

A matrix CI job that needs two branches at once (for example to diff or build both) can use worktrees to avoid a second clone, sharing object storage between trees.

### In CI?

Worktrees share the object database, so a second worktree is far cheaper than a second clone when a job needs two refs at once. Remember to git worktree remove (or prune) at the end so cached repos do not accumulate stale trees.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt