GitLab: what it is and how to work with it through Git - clone, push, merge request, CI/CD

What GitLab is

GitLab is a platform where Git repositories are stored and where team work is organized: code browsing, merge requests, issues, a wiki, a container registry and built-in CI/CD. In short, GitLab is "GitHub with its own build pipeline that you can run on your own server." Many companies keep their code in GitLab installed on an internal network.

The project started in 2011 as an open application for hosting code. A company, GitLab Inc., grew up around it. The platform comes in two editions: Community Edition, an open version you can install on your own server for free, and Enterprise Edition, which has paid features. On the cloud service gitlab.com, the plans are called Free, Premium and Ultimate.

It is important not to mix up the concepts. Git is a version control system, a program on your computer. GitLab is a service that holds a remote copy of the repository and adds an interface and team tools on top. You cannot work with GitLab without Git, but Git works perfectly well without GitLab.

Git and GitLab: the difference

People often search for "git and gitlab what is it" when both words appear in a job posting or on the first day at work. The difference is like the one between a document and a cloud storage service. Git tracks changes to files and keeps the commit history and branches locally. GitLab receives that history over the network and shows it in the browser.

You still do all the code operations, such as commit, branch and merge, in Git. GitLab only receives the result through git push and lets you discuss it with colleagues.

GitLab and GitHub: how they differ

Both services host Git repositories and support code review, so the basic skills transfer one to one. The differences lie in emphasis and in the deployment model.

In practice, many developers use both: personal projects and portfolios on GitHub, and work code in a corporate GitLab. The Git commands are the same. Only the address of the remote repository changes.

gitlab.com or your own server (self-hosted)

The cloud service gitlab.com suits personal projects and small teams. You sign up and create repositories right away. Updates, backups and availability are GitLab's responsibility. The limits of the free plan (number of members, CI minutes, storage size) change from time to time, so check the pricing page for current terms.

A company installs self-hosted GitLab on its own server, from a Linux package, in Docker or in Kubernetes. The code never leaves the internal network, you can connect corporate sign-in through LDAP, and you can set up your own runners for builds. In return, the administrators are responsible for updates and backups. For a developer the difference is barely noticeable. The address will not be gitlab.com but something like gitlab.company.example.

Setting up Git to work with GitLab

Before your first commit, set your name and e-mail. They go into the history, and GitLab uses the e-mail to link your commits to your profile:

git config --global user.name "Ivan Petrov"
git config --global user.email "ivan@example.com"

On Windows, it is convenient to work in Git Bash. It is installed together with Git for Windows and includes ssh-keygen, so all the commands in this article work there without changes. Next, choose a sign-in method: HTTPS with a token, or an SSH key.

Signing in over HTTPS: personal access token

For Git operations over HTTPS, do not use your account password. If two-factor authentication is enabled, the password will not work anyway. Instead, create a personal access token in your GitLab profile settings (the Access tokens section). For working with code, the read_repository and write_repository scopes are enough. Set an expiry date and save the token right away, because it will not be shown again.

On the first push or clone, Git asks for a login and password. Enter your GitLab user name, and enter the token in place of the password. The credential manager (built into Git for Windows) remembers it, so you will not have to type it again.

Signing in with an SSH key

SSH is more convenient for everyday work. Add a key once, and then you do not type anything else.

ssh-keygen -t ed25519 -C "ivan@example.com"
cat ~/.ssh/id_ed25519.pub

Paste the contents of the .pub file (the public key) into the SSH Keys section of your GitLab profile settings. To check the connection:

ssh -T git@gitlab.com
Welcome to GitLab, @ivan.petrov!

Git clone GitLab: how to clone a repository

The project page has a Code button with two addresses, one for SSH and one for HTTPS. Copy the one you need and run git clone:

# over HTTPS
git clone https://gitlab.com/my-group/my-project.git

# over SSH
git clone git@gitlab.com:my-group/my-project.git

In GitLab, a project path can include subgroups, for example gitlab.com/company/backend/api.git. That is normal. Copy the whole address.

Git clone GitLab with a token

In scripts and on servers where nobody can type a password, the token is passed straight in the address. The login can be your user name or the service name oauth2:

git clone https://oauth2:YOUR_TOKEN@gitlab.com/my-group/my-project.git

Keep in mind that such an address is saved in .git/config and may end up in your shell history. For automation, use a deploy token or a project access token with minimal permissions and a limited lifetime. In CI, use the built-in CI_JOB_TOKEN variable.

Git push to GitLab: sending your code

If the project already exists locally, create an empty project in GitLab (without a README, so that there is no extra commit) and link the remote repository:

git remote add origin git@gitlab.com:my-group/my-project.git
git branch -M main
git push -u origin main

The -u flag links the local branch with the remote one. After that, git push and git pull are enough. The normal workflow is no different from any other service:

git switch -c feature/login
git add .
git commit -m "Add login form"
git push -u origin feature/login
git pull

Tags are sent separately: git push origin v1.2.0, or all of them at once with git push --tags. In GitLab, tags appear in the Tags section, and they often trigger a release pipeline.

Common git push errors in GitLab

• HTTP Basic: Access denied — the login is wrong, or you entered a password instead of a token. Create a token with the write_repository scope and delete the old entry from the credential manager.
• Permission denied (publickey) — GitLab does not recognize your SSH key. Check that the public key is added to your profile, and run ssh -T git@gitlab.com.
• You are not allowed to push code to protected branches — the branch (usually main) is protected. Push your changes to your own branch and open a merge request.
• rejected ... (fetch first) — the server has commits you do not have. Run git pull --rebase and push again.
• remote: Project not found — a typo in the address, or you have no access to the project. Ask the owner about your role.

Merge request in GitLab

A merge request is the GitLab equivalent of a pull request on GitHub: a request to merge your branch into the main one. This is where colleagues leave comments on code lines, CI checks run, and the decision to merge is made. After you push a new branch, GitLab prints a link for creating an MR in the terminal, and the web interface offers to create one as well.

You can also create an MR from the command line using push options:

git push -o merge_request.create -o merge_request.target=main origin feature/login

A typical process is: a branch for the task, commits, push, an MR, review and a green pipeline, then merge. When merging, GitLab can squash the commits into one and delete the source branch. If the MR has a conflict, the easiest fix is to update the branch locally with git pull --rebase origin main or git merge main, resolve the conflicts and push again.

Mark unfinished work as Draft. Such an MR cannot be merged by accident, but colleagues can already see the changes and discuss them.

CI/CD in GitLab: .gitlab-ci.yml

The main feature of GitLab is built-in CI/CD. Put a .gitlab-ci.yml file in the root of the repository, and on every push GitLab starts a pipeline made of stages and jobs. Jobs run on runners. gitlab.com has shared runners, and on your own server you install runners separately.

stages:
  - test
  - deploy

test:
  stage: test
  image: python:3.12
  script:
    - pip install -r requirements.txt
    - pytest

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    - if: $CI_COMMIT_TAG

Here the tests run on every push, and the deploy job runs only when a tag is pushed: git tag v1.0.0 and then git push origin v1.0.0. Pipeline results are visible right in the merge request, and you can block the merge until the checks pass.

How to delete a repository in GitLab

Git commands cannot delete a project on the server. git push only changes branches and tags. You delete a project in the web interface: open the project settings, go to the General section, expand Advanced, and use the delete button, which asks you to confirm the project name. You need the Owner role. The local copy stays, because it is just a folder with a .git directory.

If you want to unlink a local repository from GitLab without deleting anything on the server, git remote remove origin is enough.

When to choose GitLab

• The code cannot be moved to an external cloud, and you need your own server.
• You want CI/CD out of the box, without third-party services.
• You work in a large organization with a hierarchy of teams, where nested groups and flexible roles are useful.
• You are joining a company that already uses GitLab. In that case you have no choice, but your Git skills transfer fully.

For portfolios and open source, people more often choose GitHub, which has a larger community and better project visibility. Nothing stops you from keeping a project on both services, because a repository can have several remotes.

Summary

GitLab is a platform for Git repositories with review through merge requests, tasks and built-in CI/CD. It is available both in the cloud and on your own server. Working with it comes down to familiar commands: set up sign-in with a token or an SSH key, then clone, commit, push, and open a merge request. Remote repositories and team workflows are covered hands-on in our Git course.