---
title: "Syncing and removing"
description: "The data of a worktree replaced, and a worktree taken away."
canonical: sync-and-remove.html
navigation-title: "Syncing and removing"
---

<a id="sync-and-remove"></a>

- [sync](#sync)
- [account](#account)
- [remove](#remove)

<a id="syncing-and-removing"></a>

# Syncing and removing

The data of a worktree replaced, and a worktree taken away.

<a id="operations-sync"></a>

<a id="sync"></a>

## sync

`ddev branchery database:sync <name> [--from=<worktree>]` ·
`POST /api/worktrees/<name>/sync`

Replaces the worktree's data with the project checkout's, or another
worktree's. The code is not touched, and neither are files outside what
`data.needs` names.

1. **Copying** `<source>` **into** `<target>`. How far this branch is
   behind the source is reported first, because that is what explains errors
   afterwards. The dump is taken, then the target is dropped and made anew,
   then the dump is loaded — in that order, so a dump that fails leaves the
   old data where it was.
2. **Putting the addresses back.** Site configuration the branch does not
   keep under version control comes along from the source, and every
   `https://….ddev.site` in it is rewritten to this worktree's address. A
   committed one is left as it is, with a line in the log; see
   [Data source and site addresses](data.md#data-source-and-site-addresses).
3. **Fitting the data to this code** (**config** `migrate`).
4. **Flushing caches** (**config**).

<a id="operations-account"></a>

<a id="account"></a>

## account

`ddev branchery worktree:account <name>` ·
`POST /api/worktrees/<name>/account`

Makes this worktree an administrator whose password is known: its own name, and
the password [the project names](configuration.md#configuration-basic) — `#Password1`
where it names none. Nothing else about the worktree is touched.

A worktree that inherited a database inherited the accounts in it, and their
passwords belong to whoever set them; a fresh installation has one this made
already. So the page states a login only where there is one to state, and offers
this where there is not.

1. **Making an account** (**config** `account`). What that means is the
   project's, and the shipped TYPO3 profiles drop an account of that name first
   — the core refuses a username that is taken and has no command that changes
   one it finds, so a second press would otherwise fail on what the first made.

Offered only where the configuration says how an account is made here, and never
on the project's own checkout: that database is the developer's, not a copy.

<a id="operations-remove"></a>

<a id="remove"></a>

## remove

`ddev branchery worktree:remove <name>` · `DELETE /api/worktrees/<name>`

1. **Removing database.** `DROP DATABASE IF EXISTS branchery_<name>`.
2. **Removing worktree.** `git worktree remove --force`, the directory, and
   the branch the worktree is on (`git branch -D`) — for a worktree that has
   wandered onto a patch, the patch's branch and not the one it was made for,
   which the question before the press names. Where git refuses the worktree --
   one holding a submodule, or a locked one — the directory goes anyway and
   the stale entry is pruned. A branch git will not delete ends the operation
   as failed, after the cleaning up.
3. **Cleaning up.** Docroot link, metadata, PHP pool assignment, the
   `ddev describe` block, and the worktree's operation history. Only the
   removal's own log stays, until the name is used again.

The list offers finished worktrees — branches merged into the project's own,
and branches deleted from the remote — for removal together, which is this
operation once per worktree. Nothing with uncommitted work in it is offered.