Why a bare repo and not your messy local tree

Think of a bare Git repository as the vault where everyone dumps commits and walks away. No working tree is kept so no one accidentally edits files on the server while trying to be helpful. This is the standard pattern for a central server repo used in team workflows CI and deployment pipelines.

Quick setup checklist

• Create the bare repo with git init --bare
• Set filesystem permissions so teammates can push and pull
• Add server side hooks to enforce rules or trigger deploys
• Use git update-ref only when you know what you are doing
• Run git update-server-info when serving over dumb http

Step by step and the commands you will actually run

Yes we will use commands because typing is cathartic. Run these on the server where the central repo lives.

Create the bare repository

git init --bare /srv/git/project.git

A bare repository stores the Git database without a checked out working tree. That makes it suitable to act as a server repo for collaborators and automated systems.

Set permissions and hooks

Make sure the Unix permissions let your team push and pull. Common approaches are a shared group or a dedicated deploy user. Put validation or deploy scripts in hooks under the hooks directory.

/srv/git/project.git/hooks

Example hook ideas

• receive hook to prevent force pushes to protected branches
• post receive hook to trigger CI or copy files to a staging area

Clone and push from a developer machine

git clone user@server /srv/git/project.git
# make changes locally
git push origin main

Using SSH access is the usual choice for security and convenience. Push and pull like normal developers do unless you have a very good reason to mess with refs directly.

Manual ref updates when you are desperate

Sometimes you need to set a branch pointer directly. This is powerful and slightly dangerous. Verify the commit hash before touching anything.

git update-ref refs/heads/branch-name 

Use this for recovery or scripted migrations only. For routine work prefer normal pushes and protected branch policies.

When to run update server info

If you are serving the repo over plain http without smart HTTP support run git update-server-info inside the bare repo. This generates auxiliary files so dumb http clients can discover refs and fetch objects. It is not required for modern smart HTTP setups but useful for simple static hosting.

cd /srv/git/project.git
git update-server-info

Best practices and safety tips

• Prefer pushes and hooks over manual ref manipulation
• Use receive hooks to validate commits and reject bad pushes
• Restrict who can push to protected branches with server side rules
• Run update server info only if you need dumb http compatibility

Summary and parting wisdom

Creating a bare repository with git init is quick and painless. Set sane permissions add hooks to enforce policies and avoid update ref unless you enjoy accidental data loss. If you are serving over dumb http remember git update-server-info so ancient clients can still fetch your genius work. Now go make commits and try not to break production on your first day.