Quick elevator pitch

If you want a place where developers send commits and not drama, a bare repository is your mailbox. This guide explains how git init, git init --bare and git clone work together to create a sane remote repository for a team. Read on for commands, reasons, and a few sarcastic asides to keep your attention.

Why choose a bare repository

A bare repository contains only the Git database and refs. There is no working tree, which means no checked out files and no risk of someone accidentally editing files on the server. Think of a bare repository as a mailbox for patches rather than a workstation for editing files. That is why bare repositories are the usual choice for central hosting in a version control workflow.

Initialize a local repository

Start where humans work. Inside your project folder run git init to create a normal repository. That command makes a .git directory which stores your commits, objects, refs and configuration. Your working tree remains the files you actually edit.

# inside your project folder
git init
# then do your usual work
git add .
git commit -m "Initial commit"

Create a bare repository for sharing

On the server or a shared filesystem initialize a bare repository. Use a name that ends with .git to avoid confusing humans and tooling.

# on the server or shared location
git init --bare repo.git

The bare repo has no working tree, so it only contains the Git database and refs. That layout makes it safe to push to and pull from, because there is nothing to accidentally overwrite on the host.

Clone the bare repository and connect remotes

Developers clone the bare repository into a working copy. The clone creates a local .git and a working tree, and it sets the original bare repo as the remote named origin.

# clone from a filesystem path
git clone /srv/git/repo.git

# or over SSH from a remote server
git clone user@server:/srv/git/repo.git

After that you work in your clone with the usual commands. Commit locally then push to origin when you are ready to share. Pull from origin to receive other people's updates.

Developer workflow and common commands

• Make changes in your working tree and stage them with git add.
• Record history with git commit.
• Send changes to the central bare repository with git push origin branch-name.
• Bring in updates from others with git pull or git fetch and git merge.
• Use git remote add origin if you need to link an existing local repo to a bare remote.

Example linking an existing repo

# on your local machine inside an existing repo
git remote add origin user@server:/srv/git/repo.git
git push -u origin main

Tips and gotchas

• Name bare repositories with a .git suffix for clarity, for example repo.git.
• Prefer SSH access for your remote repository for security and convenience.
• Remember that a bare repo has no working tree, so you cannot run builds or tests against checked out files on the server without checking out elsewhere.
• File permissions and hooks still matter, so check them on the server if pushes fail mysteriously.

Recap

Initialize a local repository with git init to do development. Create a central bare repository with git init --bare to serve as a remote repository. Clone that bare repo with git clone to get working copies that developers can commit, push and pull from. Follow these steps and your developer workflow will be less chaotic and more under control, which is a small miracle in software development.