Quick overview

Want to shove a local project up to an already existing GitLab repository without performing ritual sacrifices to the command line gods? This guide walks you through the sane sequence of commands to create a local repo with git init add files commit them and push to an existing GitLab repo. Optional SSH keys are included so you can stop typing your password like an amateur.

What you will do

• Make the project folder and add files
• Initialize a local Git repository with git init
• Add the remote that points to the existing GitLab repo
• Stage commit and push with git add git commit and git push
• Verify the push on GitLab and optionally configure branch protection and CI
• Optional set up SSH keys so pushes do not ask for a password

Create the project folder and files

Make a directory for your project and drop in your code documentation or whatever sparks joy. If you forget a file right now you can add it later. For example on macOS or Linux:

mkdir my-project
cd my-project
# add your files or copy them in

Initialize a local Git repository

Turn the folder into a Git repo with:

git init
git add .
git commit -m 'Initial commit'

That creates a local snapshot of your work. If your repo has a specific primary branch name use that name later when you push. Lots of projects use main these days but some stubborn places still use master or another branch name.

Add the existing GitLab remote

Get the remote URL from the GitLab project page then point your local repo at it. Replace REMOTE_URL with the HTTPS or SSH URL shown by GitLab.

git remote add origin REMOTE_URL
# verify
git remote -v

Stage commit and push

Push the branch to GitLab. If your primary branch is main run this:

git push -u origin main

If the remote expects master or develop change the branch name accordingly. The -u or --set-upstream option links your local branch to the remote branch so future git push calls are simpler.

Verify and secure the repo

Open the GitLab project page and confirm the files landed where you expected. If you are working on a team set up branch protection rules merge request requirements and pipeline triggers as needed to match your DevOps workflow. That way nobody can push their way into chaos without passing a check.

Optional SSH keys for password free pushes

If you do not enjoy typing credentials generate an SSH key and add the public key to your GitLab profile. A common modern choice is Ed25519.

ssh-keygen -t ed25519 -C 'your_email@example.com'
# then copy the public key
cat ~/.ssh/id_ed25519.pub

Paste that public key into GitLab under User Settings then SSH Keys. After that pushing over SSH does not ask for a password and life becomes marginally better.

Troubleshooting tips

• If git push fails check your remote URL with git remote -v and ensure you have permissions on the GitLab project
• If you see authentication errors switch between HTTPS and SSH to see which method your environment prefers
• If you pushed to the wrong branch you can create a merge request on GitLab or delete and re push the correct branch from local

Recap and final thought

You created a local project initialized Git added a remote and pushed code to an existing GitLab repository. You also learned how to set up SSH keys and where to look if things go sideways. Now go enjoy your slightly less annoying CI pipeline. Or at least pretend to.