TL;DR: Stop the loop from recreating the branch. Have the agent check whether the branch already exists on the remote and update it in place, or delete the stale branch once and let dependabot manage its own branches afterward. The updater creates its branch ref on the first run, so a second create for the same ref always fails.

```text
reference already exists
```

1. Confirm the branch is really there. Run `git ls-remote --heads origin [BRANCH-NAME]`.
Expected: the branch is listed. The ref exists, so any fresh create of the same name fails by design.
2. Fix the loop: change the agent to check for the branch first and, when it exists, fetch it and update it in place (rebase or reset onto the new base) instead of creating it.
Expected: the next loop iteration pushes an update to the existing branch instead of erroring on create.
3. If the branch is stale and you want a clean slate, delete it once from the remote with `git push origin --delete [BRANCH-NAME]`, then let the normal dependabot run recreate it.
Expected: the delete succeeds, and the next dependabot run creates the branch without collision.
4. Re-run the dependabot update job.
Expected: the job completes and the branch reflects the new update, with no reference error in the log.

## Use this when
- a rebase or sync loop deletes and recreates dependabot branches
- dependabot logs show the updater failing to create a branch that ls-remote shows exists
- two automations (dependabot plus an agent) both manage the same branch

## Not for this skill when
- the branch does not exist on the remote; the error then comes from a stale local ref, so prune with git fetch and retry
- the failure is a merge conflict inside the update; that is a resolution problem, not a ref problem
- dependabot itself is failing to compute the update; check the updater logs for the underlying package error

## Variant phrasings
### dependabot cannot create branch because it already exists
### dependabot update fails pushing existing branch
### rebase bot loop collides with dependabot branch
### dependabot reference exists error on branch create

## Why it happens
Git refs are unique per name on the remote. Dependabot's updater creates its branch the first time it processes an update, and that ref persists. An agent loop written as "delete branch, create branch, push" races this: if the delete did not land, or dependabot recreated the branch between the agent's delete and create, the create hits the existing ref and the whole update fails.

## Edge cases
- If the agent must rewrite history, prefer a force push with lease semantics over delete-plus-create; the lease fails safely if someone else updated the branch first.
- Two agents managing the same branch (one for security updates, one for version updates) will keep colliding; give each its own branch naming or let dependabot own the branch entirely.
- A branch that exists locally but was deleted on the remote confuses the check; run git fetch with prune before testing existence.
- After fixing the loop, watch one full cycle. Loops that "usually work" often still race dependabot's own scheduled runs once a day.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5Rhsno0u4pyE9Eg1as4AQg