This guide shows how to create a remote Git repository from a local project and push it cleanly without origin confusion, permission failures, or missing branches. It is a practical step-by-step flow with setup, verification, error recovery, and post-push checks I have used repeatedly on Linux and Rails deployment projects. We will cover bare repository creation, remote wiring, first push behavior, permission fixes, and validation checks, then point to the Git and SVN hub for next steps.

When this workflow is the right fit

Use this path when your code already exists locally and you need a shared remote now. Typical triggers:

  • A solo project is becoming a team project.
  • A server-side repository is needed for deployment pulls.
  • You are replacing ad-hoc zip transfer habits with proper versioned collaboration.

If your local folder is not a repository yet, initialize first and make a baseline commit.

Step 1: Prepare the local repository

Confirm state before creating the remote. A clean starting point prevents accidental omissions.

1
2
3
git status
git log --oneline -n 5
git branch -vv

If there is no repository yet:

1
2
3
git init
git add .
git commit -m "Initial commit"

Step 2: Create a bare repository on the remote host

A shared push target is usually a bare repository. Bare means no checked-out working tree, which prevents accidental edits on the remote endpoint. The official concept is documented in the Git documentation at git-scm.com.

On the target server:

1
2
3
mkdir -p /srv/git/project.git
cd /srv/git/project.git
git init --bare

Set directory ownership so your push user can write objects and refs.

Step 3: Wire the remote in your local repository

1
2
git remote add origin user@your-host:/srv/git/project.git
git remote -v

If origin already exists, inspect it. Do not blindly overwrite unless you intend to replace it.

1
git remote set-url origin user@your-host:/srv/git/project.git

Step 4: Push branches intentionally

For first push, set upstream and send only the branch you want as the initial baseline.

1
git push -u origin main

If the repository uses master or a custom branch name, push that branch explicitly.

Step 5: Verify remote state

On local:

1
2
git branch -vv
git ls-remote --heads origin

On remote:

1
2
cd /srv/git/project.git
git for-each-ref --format="%(refname:short) %(objectname:short)"

The branch hashes should match what you expect from local history.

Common errors and fast recovery

Permission denied (publickey)

Check SSH key presence, authorized_keys, and file permissions in the remote user account.

remote: fatal: unable to create temporary object directory

Ownership on the bare repo path is wrong. Fix owner and group, then retry push.

src refspec main does not match any

No commit exists on that branch yet, or you are using a different branch name.

Push rejected due to non-fast-forward

The remote branch has commits you do not have locally. Fetch and reconcile first:

1
2
git fetch origin
git log --oneline --left-right --graph origin/main...main

Practical caution

Do not store a bare repo under random home directories with mixed permissions. It works until the first maintenance rotation. Use one stable directory, one operational group, and explicit ownership policy.

FAQ

Should I create one bare repo per project?

Yes. Keep one dedicated bare repository per project for clean access boundaries.

Can I push tags now or later?

Either is fine. I usually push tags after branch baseline verification.

Is HTTPS remote better than SSH?

For automation and server-side operations, SSH is usually simpler to maintain.

Filed under