GitHub or GitLab: where the pipeline lives

GitHub and GitLab both host git, and a clone from either is the same object store with the same history. The choice is about everything surrounding the repository: where issues live, where the build runs, how permissions are expressed, and where the installation itself sits. That last part is what a client should test first, because the question that decides a supplier relationship is not which product has the better review screen — it is who can take the repository out, and whether they need the vendor's permission to do it.

Is git the thing you are choosing?

No. git is a protocol and a data model, freely implementable, and a full copy of a repository fits in a git clone. If version control were the only requirement, either platform would be an unnecessary dependency: a bare repository on a server you own does the job.

What is actually chosen is the platform: an identity system, an issue tracker, a build service with runners, a registry, a permissions model, and the integrations a team's other tools expect to find. Those are the parts that do not travel, and they are what the decision is about.

What does each platform put around the repository?

GitHub's centre of gravity is the network. Almost every open-source library, every contractor and every third-party tool has an integration written for it first, and the review flow — fork, branch, pull request, review, merge — is the vocabulary the industry uses. A new developer has used it before.

GitLab's centre of gravity is one application covering the whole path. The issue board, the pipeline, the registry, the environments and the permissions are one product with one identity model, and the same product can be installed on hardware you control. A team that wants the request, the change, the build and the deploy visible in one place gets that without three vendors.

Neither difference is about quality. It is about whether the work wants to be spread across best-in-class integrations or contained in one system with one set of logins.

What changes when you host it yourself?

It changes who holds the code and the build logs, and which country they sit in. That is a residency question first: an auditor, a public-sector client or a group policy may require the source and the pipeline to sit on infrastructure the company controls, and no feature list settles that.

It also changes control. Your runners can reach an internal database; the patch cadence is yours; an outage is yours too, and so is the upgrade that breaks an integration. A self-hosted installation needs an administrator, a backup somebody has restored once, and a maintenance window that has been agreed rather than assumed.

Cost is the wrong frame here, though it is the frame most comparisons reach for: the licence arithmetic belongs on the vendor's page, the residency requirement in a sentence your auditor would accept, written before the shortlist exists.

What breaks when you move?

The code travels perfectly. That is the easy half and it misleads people: a clone carries every commit, branch and tag, so the migration looks finished on the first day.

What does not travel is everything attached to it. Issue numbers are reassigned, so a commit message that says #412 now points at a different issue, and the link survives as text while ceasing to be true. Comments lose attachments and cross-references, labels and milestones map imperfectly, and open pull requests usually have to be reopened by hand. Pipeline definitions are similar YAML with different keys, so a build is rewritten and retested rather than copied. Team structure and permissions rarely map one-to-one.

The same is true in both directions, so "we can always move" is only true if somebody has moved one small repository once and timed it.

Who can export the repository, and without whose permission?

The test belongs before the decision. On a clean machine: clone with full history; export the issues, comments and labels; confirm the pipeline definition is a file in the repository rather than a setting in a panel; follow the README until the tests run.

If any step needs an administrator to press a button, or a support ticket, the company does not hold a copy — it holds a promise. A backup that requires the vendor's cooperation is a dependency, and the day it matters is the day the cooperation stops.

The export should also be scheduled rather than remembered. Once a quarter, into storage the company controls, is enough to make the question academic.

How do they compare where it matters?

Dimension	GitHub	GitLab
Centre of gravity	The network of contributors, libraries and integrations	One application from request to deploy
Self-hosting	A separate server product	The same product, installable
What does not migrate	Issue numbers, comments, pipeline keys	The same, in the same places
What to verify first	Who owns the organisation and can export it	Which installation you would run, and who administers it

How should a team decide?

1. List what the team uses beyond git: issue tracker, pipeline, registry, wiki, code review, security scanning.
2. List who will work in it — employees, contractors, agencies, the client's own staff — and whether they already have accounts.
3. Write the residency requirement if one exists, in a sentence an auditor would accept, and treat it as a constraint.
4. Run the export test on one real repository before the choice, not after it.
5. Choose on the constraint that cannot be negotiated, then break ties on the integrations the team already depends on.
6. Record the exit in writing: who exports, in what format, how often, and where the copy goes.

Where this goes wrong

• Choosing on the logo. The better-known name is adopted and nobody tests whether the issues and the pipeline can leave it.
• Self-hosting without an administrator. Installed by a contractor, upgraded by nobody, and a version behind within a year.
• The pipeline as a black box. A build configured in a panel by one person, undocumented, and impossible to reproduce anywhere else.
• Issue numbers used as identifiers. A commit that references one resolves to a different issue after a migration, silently and permanently.
• Two platforms for one project. Half the issues here and half there, and no single answer to what is outstanding.

What this advice leaves out

No comparison of what each plan contains, no timings of build jobs, and no claim that one is better in general: these products change faster than an argument about them stays true. It also leaves out the non-git alternatives and the procurement rules that can settle the question before engineering is consulted.

We work in both platforms, resell neither and take no commission, so nothing above is a recommendation of a vendor.

We build the pipeline and the exit together, in the client's account, so that leaving is a procedure rather than an incident.