Git worktrees and merge queues for coding agents
A Git worktree gives an agent a separate working directory and index. A merge queue controls how proposed changes enter a shared branch. Teams can use both to isolate local work and check integration.
By Nerudo. Updated October 18, 2026.
Give each agent a place to work
Git supports multiple working trees attached to one repository. Separate directories can hold different branches while sharing repository data. This helps agents avoid overwriting each other's local files. See the Git worktree documentation.
For example, start from a clean checkout that has a local main branch. The following commands create two branches and two sibling directories. The branch names and directories must be unused.
git worktree add -b agent/receipt-format ../receipt-format maingit worktree add -b agent/settings-help ../settings-help mainThe first agent works in ../receipt-format. The second works in ../settings-help. Each directory has its own checked-out branch and index. These commands do not configure credentials, checks, reviews, or a merge queue.
The agents can still change behavior that depends on another proposal. Separate directories do not establish an integration order or test the combined result. They do not authorize a merge.
Give changes a path to main
A merge queue evaluates proposed changes as they approach the target branch. GitHub's merge queue checks queued pull requests with the latest target branch and earlier queued changes. It uses the repository's required checks. See GitHub's merge queue documentation.
Nerudo combines Git hosting with a sequencer that is the only writer of trunk. Its task and change records retain context, checks, decisions, and landing receipts. Team supports competing approaches and compatible changes in batches. The current plan and repository policy determine the available workflow.
For the example above, each agent submits its own proposal. A reviewer checks the receipt formatting and settings behavior. The integration process then checks the proposed combination under repository policy. Worktrees and integration checks cover separate parts of this process.
Choose the layer that solves the problem
| Situation | Useful first step | Remaining decision |
|---|---|---|
| Agents overwrite local files | Use separate worktrees or checkouts. | How to review and integrate their proposals. |
| Passing changes fail together | Test the proposed integration state. | Which checks detect the shared behavior dependency. |
| The existing hosting and queue work well | Retain them unless an evaluation identifies a specific gap. | Whether a platform change justifies setup and migration costs. |
| A reviewer compares competing approaches | Keep task criteria, diffs, context, and checks together. | Who chooses the approach and which approvals apply. |
| A team wants connected task and landing records | Evaluate Nerudo with one bounded task. | Agent credentials, plan fit, CI setup, and proof of landing. |
Evaluate with one real task
- Choose a task with acceptance criteria a reviewer can verify.
- Record the setup time and credential requirements.
- Submit one proposal through the repository's normal workflow.
- Examine its context, diff, and checks.
- Compare the landing receipt with the resulting trunk commit.
- Introduce a second task to examine concurrent integration.
- Record failures as well as successful landings.
Use a plan that supports competing attempts if the evaluation needs them. Keep an actual coding-provider run distinct from a scripted demonstration.
Read how Nerudo's merge queue coordinates agents and the Codex setup guide. The About page, current plans, and scripted demo explain product fit before setup.