Introduction

You can absolutely use a local Git repository as a remote. In practice, the cleanest way is to create a bare repository, because a bare repo is designed to receive pushes and does not have a working tree that could get out of sync.

Why a bare repository is the right choice

A normal repository has checked-out files. If you push into a non-bare repository that has a checked-out branch, Git may reject the push or leave the working copy in an awkward state.

A bare repository contains only the Git database and refs. It behaves like the repositories hosted by GitHub or GitLab, just stored on your filesystem.

Create a local bare repository

Suppose you have a project in myapp and want a local remote in /tmp/myapp-remote.git:

mkdir -p /tmp/myapp-remote.git
git init --bare /tmp/myapp-remote.git

Now add it as a remote from your working repository:

cd myapp
git remote add local /tmp/myapp-remote.git
git push -u local main

At this point, local behaves like any other remote.

You can also use an existing local path

If the target repository already exists and is bare, add it directly:

git remote add backup /Users/markqian/repos/project-backup.git
git push backup main

Git does not care whether the remote is on the internet, on another disk, or just another folder on the same machine. A filesystem path is a valid remote URL.

Cloning from the local remote

Once the bare repository exists, other local clones can use it too:

git clone /tmp/myapp-remote.git another-copy

That is useful for:

• local backup remotes
• testing push and fetch workflows
• sharing repositories across mounted drives or internal networks

Using file:// versus a plain path

Both of these are valid:

git remote add local /tmp/myapp-remote.git
git remote add local file:///tmp/myapp-remote.git

A plain path is usually simpler on the same machine. The file:// form is more explicit and can matter in some scripted or cross-platform setups, but for day-to-day local work, the path form is enough.

If you really want a non-bare repo as remote

It is technically possible to push to a non-bare repository, but it is rarely the right answer. The checked-out branch can conflict with incoming pushes, and the receiving repository may need special settings such as receive.denyCurrentBranch.

For most cases, if you are asking how to treat a local repo like a remote, what you actually want is a bare repository.

Verifying the setup

List your remotes:

git remote -v

Then push and fetch as usual:

git push local main
git fetch local

If those commands work, the local remote is configured correctly.

Common Pitfalls

• Using a non-bare repository as the remote target and running into checked-out branch issues.
• Forgetting to push an initial branch after adding the remote.
• Assuming a "remote" must be hosted on GitHub, GitLab, or over SSH.
• Confusing a local clone with a bare remote repository.
• Moving or deleting the target folder after adding it as a remote path.

Summary

• A local Git repository can be used as a remote, and a bare repo is the safest way to do it.
• Create it with git init --bare /path/to/repo.git.
• Add it with git remote add name /path/to/repo.git.
• Push and fetch normally once the remote is configured.
• Avoid non-bare remotes unless you have a very specific reason and understand the trade-offs.