# Manage repository settings Use **Settings → General** (`///settings`) to manage visibility, the default branch, transfers, retained branches and repository deletion. Administration requires the permissions described below. If settings change while you are editing, reload and review the current values before retrying. The **Settings** tab is available to repository maintainers and administrators, not ordinary readers of a public repository. Direct settings access requires sign-in (401); signed-in readers without sufficient authority receive 403. Missing repositories and private repositories you cannot access remain 404. API credentials also need repository metadata-read scope to read General settings; editing requires metadata-write scope. Individual administration actions retain their stricter permissions below. Description, homepage, topics and automatic branch deletion are saved together with **Save changes** in the header. **Discard** restores the latest loaded values. Leaving with unsaved edits asks for confirmation. Other administration actions use their own confirmation dialogs. ## Deleting a repository Only the owner can delete a repository. 1. Find **Delete this repository** and press **Delete repository**. 2. Type the full `owner/name` exactly as shown. 3. Press **I understand, delete this repository**. Once accepted, the repository becomes inaccessible and disappears from normal repository lists and code views. **Deletion does not currently erase the stored Git data.** This workflow offers no repository restore action. ## Changing visibility Repository administrators can change a standalone repository between public and private in General settings. Publishing makes its content accessible to anyone. Private repositories require an eligible plan on instances that enforce plan limits. For a repository connected through an active GitHub App mirror, you must be able to renew GitHub authorization. A public GitHub source may sync to either visibility; a private source requires a private destination. The selected sync mode and conflict preference are preserved. Wait for pending synchronization to settle before changing visibility. Visibility changes are unavailable for GitCafe fork networks and mirrors without active, renewable GitHub authorization. A source being a fork on GitHub is a separate property and does not by itself impose that restriction. ## Changing the default branch Administrators can choose a default branch in General settings or use `cafe repo edit --default-branch `. Select an existing branch; an empty repository can name its initial branch. The default determines what people see when opening or cloning the repository. New repositories default to `main` unless you choose another name during [creation](https://git.cafe/docs/repositories/repository-create.md). Forks inherit their parent's default branch. If changing the default branch is unavailable on your instance, the request says so. A pending or uncertain result does not mean the change failed: inspect the existing operation before starting another change. ## Transferring a repository Use **Transfer repository** in General settings. Enter the destination owner, an optional new name, and the current full repository name. You need permission at both the current owner and the destination. Conflicting work can prevent the transfer. After a successful transfer: - Update your local Git remote to the new address. - Review access: source-organization team access is removed, while direct collaborator access remains. - Reauthorize GitHub synchronization under the new owner; sync is paused by the transfer. The CLI also exposes `cafe repo transfer`. ## Deleting a branch or tag Repository writers can delete eligible branches and tags from their [branches](https://git.cafe/docs/repositories/branches.md) or [tags](https://git.cafe/docs/repositories/tags.md) page, or through the CLI. Review the selected ref before confirming. If it changed after the page loaded, refresh before retrying. Deletion is unavailable for the default branch, the branch used by Git HEAD, refs used by open pull requests, fork networks, and GitHub mirrors. Matching active deletion protections also apply; only an unconditional bypass can skip them. Other review requirements do not themselves prevent deletion. An accepted request may still be pending. If the response is lost or the outcome is uncertain, use **Deletion activity** or the CLI's ref-deletion commands to inspect the existing operation. Inspection does not start another deletion. Only the account that started it, with current repository write access, can inspect the operation. ## Restoring a deleted branch In General settings, expand **Deleted branches**, search retained branches, and choose **Restore** to recreate a branch at its recorded commit. You need repository write access. A branch with the same name must not already exist, and the retained branch data must still be available and unchanged. An accepted restore may still be pending. Use **Check restore status** to inspect it; the page reports **Branch restored** after confirmation. This workflow restores retained branches, not tags or deleted repositories.