"Renaming a Git repository" usually means one of two things, and they are completely independent of each other:

- **The local folder** your working copy sits in. Git does not store this name anywhere — it is just a directory.
- **The repository name on your host** (GitHub, GitLab, Bitbucket), which is part of the clone URL every collaborator and deployment tool points at.

Changing one does not change the other. Neither one touches your commit history.

## Rename the local folder

There is no Git command for this, because Git does not care what the folder is called. Use your shell:

```bash
mv old-project-name new-project-name
```

Your history, branches, remotes, and configuration all live inside the `.git` directory, which moves with the folder. Nothing else needs updating.

## Rename the repository on GitHub

1. Open the repository and go to **Settings** (you need admin access).
2. In the **General** section, find the **Repository name** field at the top.
3. Enter the new name and click **Rename**.

GitHub sets up redirects from the old URL to the new one for both web traffic and Git operations, so existing clones keep working for a while. Treat that as a safety net rather than a fix, not least because plenty of tooling does not follow redirects at all.

One important caveat: if someone later creates a new repository using your old name, the redirect stops working immediately.

## Rename the repository on GitLab

GitLab splits this into two separate fields, and changing one does not change the other:

- **Project name** (the display name) — **Settings → General → Naming, topics, avatar**.
- **Project slug** (the part in the URL) — **Settings → General → Advanced → Change path**.

If your goal is to change the clone URL, you need to change the **path**, not just the name. Renaming only the display name leaves the URL untouched, which is a common source of confusion.

GitLab creates a redirect from the old path, with the same caveat as GitHub: it is released if the old path is claimed again.

## Rename the repository on Bitbucket

1. Go to **Repository settings → Repository details**.
2. Update the **Name** field.
3. Check the repository **slug** on the same screen — Bitbucket derives it from the name, but you can edit it independently.

As with GitLab, the display name and the URL slug are distinct. Confirm the slug actually changed before assuming the clone URL did.

## Update your local remote URL

This is the step people miss. Renaming on the host does not update any clone that already exists on disk.

Check what your clone currently points at with [`git remote`](/git/commands/git-remote):

```bash
git remote -v
```

Point it at the new URL:

```bash
# SSH
git remote set-url origin git@github.com:username/new-name.git

# HTTPS
git remote set-url origin https://github.com/username/new-name.git
```

Then confirm the change took effect:

```bash
git remote -v
```

Every collaborator with an existing clone needs to run this too. The alternative is deleting their local copy and [cloning the repository](/git/cloning-an-existing-repository) fresh.

## What a rename breaks

Host-side redirects cover `git clone`, `git fetch`, and `git push` — but plenty of things reference the repository URL and will not follow a redirect:

| What | Why it breaks | Fix |
|------|---------------|-----|
| CI/CD and deployment configs | Pipelines pin the full clone URL | Update the repository URL in each service |
| [Submodules](/git/commands/git-submodule) | `.gitmodules` stores an absolute URL per submodule | Edit `.gitmodules`, then run `git submodule sync` |
| Webhooks pointing *at* the repo | Payload URLs and signatures may embed the old path | Re-check each webhook target |
| Hard-coded links in docs and READMEs | Plain text, not a Git reference | Search and replace |
| Badge and package URLs | Shields, registries, and package manifests cache the path | Update the manifest |

For submodules specifically, editing `.gitmodules` is not enough on its own:

```bash
git submodule sync
git submodule update --init --recursive
```

`git submodule sync` copies the new URLs from `.gitmodules` into `.git/config`, which is what Git actually reads when fetching.

Deploy keys and SSH credentials generally survive a rename, because they are attached to the repository object rather than its name. Access tokens scoped to a specific path are the exception — check those.

## Summary

| Goal | Action |
|------|--------|
| Rename the local folder | `mv old-name new-name` |
| Rename on GitHub | Settings → General → Repository name |
| Rename on GitLab | Settings → General → Advanced → Change path |
| Rename on Bitbucket | Repository settings → Repository details → Name (check the slug) |
| Repoint an existing clone | `git remote set-url origin <new-url>` |
| Verify | `git remote -v` |
| Fix submodules | Edit `.gitmodules`, then `git submodule sync` |

Renaming a branch is a different operation with different commands — see [how to rename a branch in Git](/git/faqs/rename-a-branch-in-git). If you are starting from scratch instead, our tutorial on [creating a repository](/git/creating-a-repository) walks through the setup.

Keeping deployments working after a rename is one less thing to think about with [DeployHQ](https://www.deployhq.com) — update the repository URL once in your project settings and automatic deployments carry on from the next push.