So you have a shiny local project and an existing GitLab repo that needs feeding. This guide will walk you through creating the project folder, initializing git, wiring up the remote, and pushing your first branch. Keep your secrets out of commits and your dignity intact.

Prepare the project folder

Create a directory and add the files that make your code actually do something. Also add a sensible .gitignore so you do not accidentally commit build artifacts or secret keys. Nobody wants a surprise CI hellscape.

mkdir my-new-project
cd my-new-project
# add code files and a .gitignore

Initialize git and set your identity

If this machine does not already have a local repo for the project, run git init then set a name and email so your commits do not look anonymous and suspicious.

git init
git config user.name "Your Name"
git config user.email "you@example.com"

Add a remote that points to the existing GitLab repository

Grab the repository URL from the GitLab project page. Use an SSH URL if you have SSH keys set up for less typing and fewer password dialog windows. Use HTTPS if you prefer the gentle pain of tokens and prompts.

# SSH example
git remote add origin git@gitlab.com:username/project.git

# HTTPS example
git remote add origin https://gitlab.com/username/project.git

Check the remote

Make sure you added the right remote so you are not pushing your life into the wrong repo.

git remote -v

Stage, commit, and push your code

Stage everything you want tracked, commit with a clear message, and push the branch to the remote. Use a descriptive branch name so coworkers can tell what the heck you were doing.

git add .
git commit -m "Initial commit"
# Replace main with your preferred branch name
git push -u origin main

New branch workflow

If you prefer not to push directly to the default branch, create a feature branch and push that instead.

git checkout -b feature/my-awesome-change
# make changes
git add .
git commit -m "Add feature"
git push -u origin feature/my-awesome-change

Authentication and common gotchas

• If authentication fails with HTTPS you may need a personal access token on GitLab. Treat it like a password but more fragile.
• If SSH fails check that your public key is added to GitLab and that your ssh agent is running.
• Large files and accidental secrets can make history messy. Use .gitignore and tools like git rm --cached if you need to back out a file.

Quick checklist before you push

• Project files are added and sensible files are ignored
• Your git user.name and user.email are set
• The remote URL points to the correct GitLab project
• You pushed the correct branch with -u origin <branch> so future git push is easy

Tips for a calmer developer workflow

• Use descriptive branch names like feature/login-button or bugfix/typo-in-readme
• Enable branch protection on the GitLab project to prevent accidental wreckage
• Create merge requests for code review and let CI catch problems before humans do

There you go. You created a local project, initialized git, pointed it at the existing GitLab repo, committed your work, and pushed a branch. If anything breaks blame the network first and your past self second. Now go write code or at least create the PR so someone else can review your glorious mess.