How to Remove a Remote Origin in Git

Most people working on a git repository, have done so by cloning a remote one. The thousands of developers who work on projects everyday, have mostly taken an existing repo and are working on it. When you do this, git sets up a connection to the remote repo and calls it the “origin”. This makes it the default option for various remote branch-related operations. For example, you can use the following command to fetch changes from the remote repo:

git fetch origin

Since the “origin” is already specified, manually writing the remote repo URLs into the variable is unnecessary. Along with fetching, you can also pull, push, and update the origin URL. The origin is like the “mother” of the local git repo.

But sometimes you need to remove the origin altogether. We might need to do this for a variety of reasons. For example, you might be beginning work on a brand new project, but need first to clone the framework or a starting point from someone else’s repo. In such a situation, you no longer rely on the original remote connection, and will probably create your own. But first, let’s see how the origin exists and how to remove it.

Cloning a Git Repo to See the Origin

To see how this works, let’s clone a git repo and see how the origin is set. GitHub provides a sample repository that we can use for testing and connection purposes, so let’s clone that one first and see what happens. We use the command:

git clone https://github.com/octocat/Hello-World.git

You can see in the screenshot below, that after git completes the clone, a new directory called “Hello-World” is created:

Once we go into the directory, we can use the following command to get the details of the remote connection called “origin”:

git remote -v

This shows the following:

You can see that the “origin” remote connection is set as both the “fetch” as well as the “push” channels. These also happen to be the default channels when you type a command like this:

git fetch

Even though you can have other remote connections, there is still a “default” one for commands like the one above where you don’t explicitly specify it.

Removing the Origin Connection

Now let’s remove the origin from git and see what happens. To do this, we use the following command:

git remote remove origin

Here’s what we see:

You can see that as a continuation from the previous screenshot when we remove the origin and run the “git remote -v” command, it shows us nothing because the connection no longer exists. We’ve essentially severed ourselves from the remote branch.

What to Do After Severance?

Once you’ve cut yourself off from the source, you have many options. Here they are:

Connect to a Different Origin Remote Repo

If you want, you can connect to a different repo instead of the old one. Or you could simply add back the original repo if you made a mistake and want to undo it. The command for this would be:

git remote add origin <URL>

Use the new URL in the above command and you have your origin back!

Add a New Connection Different from “Origin”

While “origin” is the default remote connection, there’s nothing sacred about the name. It’s used as the default simply because it’s the first one to be added when you clone a repo. But if you want, you can add a new remote connection and call it something else. A common naming convention is “upstream”, and you can create one like this:

git remote add upstream <url>

Then use it like you would the “origin” connection.

Create a New Online Repo

You can also use your local repository as the basis for a new online repo. To do this, simply follow my tutorial on how to connect a VPS to GitHub. Once you have the URL of your new repository, simply add it as a new remote connection and you’re done! The next time you push your changes, all your local files will be uploaded to the remote repo.

Keep Your Project Offline

You may want to work on your project offline, in peace. This is true particularly if it’s a personal project, and you don’t need to share your code with anyone. I’ve worked on codebases like this myself. While you might eventually want to push it to an online repo, there’s no hurry and you might even never do so.

As a matter of prudence, however, it makes sense to have some kind of online backup. Perhaps you feel that a full remote git branch is overkill, but it’s not as if git takes up too much space anyway. Even if you don’t intend to share your code with anyone, having a remote repository from which you can push your changes or pull is incredibly useful in case something happens to your local workstation.

If you work online, you can still commit, create a new branch, merge branches, and view git history.

Create a Local “Remote” Repo

It sounds strange, but git also allows you to create a “local remote” repository. This means that you still push and pull your changes to a repo, but they’re hosted on the same server instead of on a remote server. The command to add a remote local repo is the same as the one for creating a regular remote repo:

git remote add backup /home/user/project-backup

In this example, git links the project to a remote local repo that serves as a backup. You can do this for a few reasons. Either your project is too large and you don’t want to have the hassle of syncing with a remote server, or you don’t have Internet access but still want to maintain the habit of pulling and pushing from a remote repo. Alternatively, this is also useful for the niche scenario of developers working separately on a codebase, but using the same machine.

Whatever the reason, it means that git repos aren’t restricted to remote locations, and you can have them offline as well.

Create a Bare Repository

Like the previous use case, you could also create a “bare” repository instead of a full-fledged local repo. Remote services like GitHub, etc are all bare repos. In a bare repo, only the history of the project is stored, and no actual files are found. From the point of view of a developer working on a local machine, there’s no difference in the interactions between a bare repo and a non-bare repo. But a bare repo is safer for collaboration and doesn’t contain unnecessary files since they can all be reconstructed from the history itself.

Conclusion

Most of the time, you’ll keep the same origin connection as the one from which you cloned your repo. But often enough, you’ll need to remove the origin so you can add another one of your own. This is particularly true if you’ve cloned a test or a framework repo and now want to recreate a new remote repo for future development. After disconnecting the origin, you have many options, including the ability to continue working on the local machine or change the URL for the origin.