Git vs GitHub vs GitLab: One Is a Program, Two Are Companies

Git is a program that runs on your laptop and records the history of your files. GitHub and GitLab are companies that host copies of Git repositories on the internet and wrap them in issues, reviews, permissions, and pipelines. You can use Git forever without either.

The names cause the confusion. GitHub and GitLab both contain the word Git because both are built around it, in the same way that a dozen email clients contain the word mail. Getting the layers straight matters practically, because it tells you which problems are Git problems (fixable locally, documented in the Git manual) and which are platform problems (fixable in a web UI, documented by a vendor).

Table of contents

• Git: the part that is not a website
• What the platforms add
• Where GitHub and GitLab actually differ
• Choosing, in practice
• The layer boundary, and why it saves you time
• How this fits the rest of the stack
• FAQ

Git: the part that is not a website

Git is a distributed version control system. It records snapshots of your project, lets you branch and merge, and works entirely offline. Every clone contains the full history, which is the distributed part and is genuinely the important design decision.

git init
git add .
git commit -m "first commit"
git log --oneline --graph
git branch feature-x
git merge feature-x

Not one of those commands needs a network connection or an account anywhere. A repository on a USB stick is a complete repository. Two developers can push and pull between each other’s machines over SSH with no hosting service in the middle.

This is worth internalising because it changes how you read errors. fatal: not a git repository is Git talking. Permission denied (publickey) is the transport. You must verify your email before pushing is the platform. Three different layers, three different places to fix things, and knowing which one you are in saves a lot of searching.

Git is also free and open source, released under the GPL, and it will still be there regardless of what any hosting company does. That is not a small property when you are choosing where to keep a decade of work.

What the platforms add

Hosting a bare repository somewhere reachable is the easy part — a server with SSH and a git init --bare does it. What GitHub and GitLab sell is everything around that.

• A canonical copy with backups and uptime that is not your problem.
• Access control — who can read, push, merge, and administer, per repository and per branch.
• Code review as a first-class object: pull requests on GitHub, merge requests on GitLab, with inline comments, approvals, and required checks.
• Issue tracking and project boards.
• CI/CD — GitHub Actions, GitLab CI — that runs on push and gates merges.
• Package and container registries.
• Identity and audit — SSO, org membership, logs of who did what.

None of that is version control. It is collaboration infrastructure that happens to be organised around a repository. That is why the choice between platforms is mostly a workflow and org question rather than a technical one — the Git underneath is identical, and moving repositories between them is genuinely easy.

Where GitHub and GitLab actually differ

The honest summary in 2026: both do everything, and the differences are about defaults, packaging, and where each one is strongest.

• Reach. GitHub is where open source lives. If your project wants outside contributors, drive-by pull requests, and to be found, that network effect is not something GitLab can match and it is the single biggest practical difference.
• Self-hosting. GitLab has always offered a full self-managed edition, with an open-core version you can run yourself. GitHub’s equivalent is Enterprise Server, positioned and priced for larger organisations. If running it on your own infrastructure is a requirement, this usually settles it.
• Built-in versus assembled. GitLab’s pitch is one application covering plan, build, test, deploy, monitor. GitHub’s is a strong core with a very large marketplace. Both work; they suit different appetites for integration work.
• CI ergonomics. GitLab CI’s single .gitlab-ci.yml is coherent and predictable. GitHub Actions has a vastly larger ecosystem of pre-built actions and a more generous free tier for public repositories. Actions is more powerful and more sprawling; GitLab CI is tidier and more opinionated.
• Terminology. Pull request versus merge request. Same concept. GitLab’s name is arguably more accurate, GitHub’s is the one everyone says.

Feature comparison tables on this subject age within months, because both ship constantly and copy each other’s good ideas. Treat any specific table, including anything implied here, as a snapshot rather than a fact.

Choosing, in practice

A short set of rules that hold up better than a feature matrix:

• Open source project seeking contributors — GitHub. The network effect is the feature.
• Regulated environment or data residency requirement — GitLab self-managed, unless you are large enough for GitHub Enterprise Server.
• Small team that wants CI working today with minimal thought — either. Pick the one your team already knows.
• Heavy investment in one vendor’s ecosystem — stay there. Integration cost is real and rarely repaid.
• Undecided — GitHub, on availability of tooling and the size of the hiring pool who already know it.

And keep the migration cost in perspective. Because the repository itself is portable, moving hosts means moving issues, CI configuration, and permissions — annoying, well-trodden, and not a lock-in trap. The genuinely sticky parts are the pipeline definitions and the muscle memory, not the code.

Bitbucket, Gitea, Forgejo, and a self-hosted git init --bare over SSH are all legitimate options too. A small team with a Linux box and no need for a web review UI can run on the last one indefinitely.

The layer boundary, and why it saves you time

Once the three layers are clear, troubleshooting gets faster because you know which manual to open.

• Git layer — merge conflicts, detached HEAD, rebases, .gitignore not working, history rewriting. Local. Fix with Git commands.
• Transport layer — SSH keys, HTTPS credentials, proxies, Permission denied (publickey). Between your machine and the host.
• Platform layer — branch protection blocking a push, a required check that has not run, a merge request needing approval, a runner not picking up a job. Fix in the web UI or in the pipeline config.

A concrete example. Cannot push to main: if the error mentions non-fast-forward, that is Git telling you your branch is behind. If it mentions protected branch, that is the platform enforcing a rule someone configured. The words look similar in a terminal and the fixes have nothing in common.

The same split applies to deployment. Git tracks the code. The platform runs the pipeline. Something else runs the result — and that third thing is a separate decision from either of the first two.

How this fits the rest of the stack

That last boundary is the one worth being deliberate about. Git holds the history, the platform reviews and gates the change, and the runtime is where it actually has to work — with its own logs, its own environment variables, and its own way of going back when a deploy misbehaves. RunxBuild connects to a repository on either platform and builds on push, keeping the build log and the runtime log attached to the deploy that produced them; deploying from GitHub on RunxBuild covers the connection and the branch settings. When you are sizing what that runtime costs — service, managed database, storage, bandwidth — the RunxBuild hosting calculator shows them as separate figures rather than one bundled number.

Useful related references:

• Bitbucket vs GitHub: A Decision About Your Toolchain, Not Your Git
• See All Branches in Git: Local, Remote, and the Ones You Forgot
• Git Server: Self-Host with Gitea, GitLab, or Bare SSH
• Deploying from GitHub on RunxBuild

FAQ

What is the difference between Git and GitHub?

Git is a version control program that runs on your machine and works entirely offline. GitHub is a company that hosts Git repositories online and adds issues, pull requests, permissions, and CI. You can use Git with no GitHub account at all.

Is GitLab better than GitHub?

Neither is universally better. GitLab has stronger self-hosting and a more integrated single-application approach. GitHub has by far the largest open source community and the biggest ecosystem of pre-built CI actions. For a public project the network effect usually decides it for GitHub.

Can I use Git without GitHub or GitLab?

Yes. Git is fully functional locally, and you can push to any server you can reach over SSH using a bare repository. Small teams run this way indefinitely. Self-hosted options like Gitea and Forgejo add a web UI without a commercial platform.

What is the difference between a pull request and a merge request?

Nothing functional. GitHub calls it a pull request, GitLab calls it a merge request, and both mean propose changes from one branch into another with review and discussion. GitLab’s name describes the operation more accurately; GitHub’s is the one in common speech.

Is it hard to move from GitHub to GitLab?

Moving the repository itself is trivial, because every clone contains the full history. What takes effort is the surrounding material: issues, CI pipeline definitions, permissions, and integrations. Both platforms provide importers, and the pipeline config is usually the biggest rewrite.