# Threads & branches

> How threads map to git branches, and how parallel work stays organized.

darting.dev maps cleanly onto git: a **project is a repo**, and a **thread is a branch**.

## Threads

A thread is one conversation with a lead agent. A project can have many threads, each with its own:

- Conversation log and execution history
- Git branch (`agent-swarm/{agentId}`)
- Sandbox cloned at that branch

Threads are numbered by creation order — Thread 1 is the first created — so they stay stable as you open and close them. Start a new one any time with **+ New Thread**, including a **private thread** that stays visible only to you.

## Branches

Git activity is automatic:

- A **user message** becomes a checkpoint you can rewind to ([checkpoints, stop & rewind](https://darting.dev/docs/checkpoints-and-rewind/)).
- **Agent output** is auto-committed and pushed after each turn.
- **Automations** run as their own agents, in their own sandboxes, and commit their results back to the repo.

```bash
# each thread works on its own branch
git checkout -b agent-swarm/3f2a   # Thread 2
# ... agent commits land here, never on main
```

## The branch graph

The Git tab renders an SVG graph of every branch:

- The default branch is the trunk; threads and automations fan out into their own lanes.
- Each commit is clickable — see its diff, message, timestamp, and +/- summary inline.
- Status badges show whether a branch has unique commits, is merged, or hit a conflict.

Because each thread is just a branch, running five things at once is no different from running one — they simply live in parallel lanes until you decide to merge.