GitLab Primer — Differences from GitHub and the Features You'll Actually Use

GitLab at work, GitHub for personal projects — a very common combination. Both are "Git repository hosting plus development support features," and the Git operations themselves are exactly the same. What differs is the tooling on top and the vocabulary. This is a guide to keep GitHub users from getting lost in GitLab.

What is GitLab?

A "DevOps platform" that integrates issue tracking, code review, CI/CD, and deployment around Git repositories. It comes in two forms:

• GitLab.com — the SaaS version. A cloud service you use just like GitHub
• Self-Managed — you run GitLab on your own servers or cloud. The GitLab at your company is almost certainly this one. It is popular with companies that cannot put code on external services, and the free Community Edition (CE) covers most needs

If your company's GitLab URL looks like gitlab.example.co.jp on an internal domain, it is Self-Managed. Upgrades are also managed in-house, so it may lag behind GitLab.com in features.

Terminology map (GitHub → GitLab)

The concepts map almost one-to-one; many things just have different names.

The Merge Request workflow in practice

Same flow as a GitHub PR; just swap the words.

git switch -c feature/add-login   # create a branch
# make changes and commit
git push -u origin feature/add-login

After the push, GitLab prints an MR-creation URL right in your terminal (a nice touch) — opening that link is the fastest way to create the MR. Then:

• Assign reviewers → review → resolve threads (GitLab's equivalent of GitHub conversations)
• Approve: the project can enforce approval-count rules (depending on settings, the merge button stays disabled until approvals are in)
• The merge method (merge commit / squash / fast-forward) is usually preselected in project settings. On squash projects, your carefully stacked commits get flattened into one
• main and develop are normally protected branches, so direct pushes get rejected. If you "can't push," check this first

GitLab CI/CD basics

The GitHub Actions equivalent is built in from the start. It lives in .gitlab-ci.yml at the repository root:

stages:
  - test
  - build

lint:
  stage: test
  image: node:22
  script:
    - npm ci
    - npm run lint

build:
  stage: build
  image: node:22
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

Conceptual differences from GitHub Actions:

• The workflow file is basically one per repository (.gitlab-ci.yml), not a folder of files like .github/workflows/ (you can split with include)
• Jobs are grouped into stages: jobs in the same stage run in parallel, and the next stage starts only after the previous one fully succeeds
• The Runner is the execution environment. GitLab.com offers shared Runners, but Self-Managed installs run on Runners your company provisioned. When "CI is stuck," it is usually a queue for free Runners
• Creating an MR triggers a pipeline whose results show up in the MR view. Requiring a green pipeline to merge is the standard setup

How they differ in philosophy and where each fits

• GitHub: the home of OSS and personal projects; doubles as every developer's profile and portfolio. Its surrounding services (Actions, Copilot, etc.) evolve fast
• GitLab: the "plan → develop → CI/CD → monitor" everything-in-one-product philosophy (The DevOps Platform). Self-Managed hosting is its biggest strength, which is why it thrives as internal infrastructure
• Feature-wise, both now cover "Git + review + CI + issues," and day-to-day development feels about the same. The differences show up on the admin/ops side (hosting model, permission hierarchy, auditing)

In practice, the most common split is exactly this: public personal repos on GitHub, internal company development on GitLab.

First things to check on your company's GitLab

1. Register your SSH key (Profile → SSH Keys). Internal GitLabs usually favor SSH clones over HTTPS
2. Your role (Guest / Reporter / Developer / Maintainer / Owner). As a Developer, being unable to push to protected branches or merge MRs is normal
3. The project's MR rules (approval count, squash or not, pipeline required or not)
4. Skim .gitlab-ci.yml so you know what runs when you push

Summary

• GitLab = Git hosting + integrated DevOps. The one at your company is almost certainly Self-Managed
• A PR is called an MR. Organization → Group, Actions → CI/CD — it is mostly a vocabulary swap, and Git usage is identical
• CI is one .gitlab-ci.yml + stages + Runners, integrated into the MR view
• When in doubt, think "GitHub's X is GitLab's Y" with the table above and you will usually be right