← Back to Git Course | Chapter 4: Remote Repositories | Lesson 10 of 11

Git GitLab Introduction

GitLab is a clubhouse for your Git projects with a built-in robot factory that automatically tests and delivers your work every time you save.
Syntax
bash
git remote add origin https://gitlab.com/user/repo.git
git clone https://gitlab.com/user/repo.git

What is GitLab?

GitLab is a web-based Git repository host built around integrated DevOps tooling, most notably its own CI/CD pipelines, issue tracking, and container registry, all in one product. You connect a local repository to it with the same git remote add workflow you'd use for any other host, so nothing about your day-to-day Git commands changes.

Example: What is GitLab?

bash
git remote add origin https://gitlab.com/user/repo.git

Cloning from GitLab

Cloning a GitLab project works over either HTTPS (prompts for a username/password or personal access token) or SSH (uses a key pair registered on your account, no password prompt). Once cloned, the project behaves like any local Git repository — GitLab only matters again when you push, pull, or open a merge request.

Example: Cloning from GitLab

bash
git clone https://gitlab.com/user/repo.git
git clone [email protected]:user/repo.git

GitLab CI/CD Basics

A .gitlab-ci.yml file at your project root defines one or more pipeline stages (build, test, deploy) that GitLab runs automatically on every push. This is what lets a team catch a broken build or failing test within minutes of a commit, rather than discovering it later during a manual release.

Example: GitLab CI/CD Basics

bash
echo "stages:\n  - build\n  - test\n  - deploy" > .gitlab-ci.yml

Working with Merge Requests

GitLab's Merge Request is functionally the same idea as GitHub's Pull Request: push a feature branch, then open a request asking for it to be merged into a target branch, with room for review comments and approval rules before merging. The renamed term trips up people switching between the two platforms.

Example: Working with Merge Requests

bash
git checkout -b add-search-bar
git push -u origin add-search-bar

Forking on GitLab

Forking on GitLab copies a project (including its full history) into your own namespace, so you can make changes without needing write access to the original. You then push commits to your fork and open a merge request back to the source project, which is the standard workflow for contributing to a repository you don't own.

Example: Forking on GitLab

bash
git clone https://gitlab.com/yourname/repo.git
git push origin main
Related Topics
{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
Common Mistakes
  1. Using your GitLab account password over HTTPS when a personal access token or SSH key is required.
  2. Naming the pipeline file gitlab-ci.yml without the leading dot, so GitLab does not run any pipeline; it must be .gitlab-ci.yml.
  3. Assuming GitLab CI runs on any push with no configuration, when jobs only run if the .gitlab-ci.yml file defines them.

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.