How do I rename a Git repository?
"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:
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
- Open the repository and go to Settings (you need admin access).
- In the General section, find the Repository name field at the top.
- 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
- Go to Repository settings → Repository details.
- Update the Name field.
- 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 remote -v
Point it at the new URL:
# 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:
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 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 | .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:
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. If you are starting from scratch instead, our tutorial on creating a repository walks through the setup.
Keeping deployments working after a rename is one less thing to think about with DeployHQ — update the repository URL once in your project settings and automatic deployments carry on from the next push.