06 — Repo Hosting: The Social and Automation Shell Around Git

I quietly confused repository hosting with Git itself, which made every host's differences feel arbitrary. The untangling: Git is the engine, and a repo host is the social and automation shell wrapped around it. Git does one job — track history as a graph of commits. The host takes that local graph and turns it into shared, reviewable, CI-able project infrastructure [1]. Once I could see those two layers separately, the differences between GitHub and GitLab stopped feeling arbitrary and started looking like different bets on which shell matters more.

Here's the picture I keep in my head — the engine on the left, the shell on the right:

What the host adds that Git alone doesn't

Git, on its own, is a local concern. I can commit, branch, and merge forever on my laptop and nobody else ever sees it. The thing that turns that private history into a team artifact is a remote — another Git repository, reachable over the network, that I push to and fetch from. A repo host is, at its core, one of those remotes that other people also push to and fetch from, plus a web UI and a set of collaboration tools built on top [1].

The shell layer is where most of what I actually recognize as "working on a project" lives:

• Pull / merge requests — a proposed change, scoped to a branch, with diff view, line-by-line review, required approvals. This is not a Git concept; it's a host concept. Git merges branches. The host stages the conversation around whether to merge them.
• Issues and project boards — a shared to-do list and tracker tied to the repository.
• Forks and permissions — a model for who can push directly and who works through a copy.
• CI/CD pipelines — automation that runs tests, builds, and deploys on events like a push or a PR, defined in a file committed to the repo itself.
• Webhooks and integrations — the host notifies other services when things happen.

The mental shift: none of that is Git. It's a product layer that speaks Git underneath. Which is why two hosts can share the exact same engine and still feel completely different — they're different shells.

GitHub: the network

GitHub is the largest repository host and the de facto home of open source [2]. Microsoft acquired it in 2018 [2]. The thing I had to understand about GitHub is that its dominant feature isn't any single tool — it's network effect. When a library lives on GitHub, its issues, its pull requests, its contributors, its dependabot alerts, its Actions marketplace, and its visibility in search all compound. For an open-source project, being somewhere a contributor can find it and file a PR in under a minute is worth more than any feature checkbox.

GitHub's automation is GitHub Actions — workflow YAML files that run jobs on runners, triggered by repo events [3]. To be clear: GitHub is end-to-end today. Actions for CI/CD, Packages for registries, Projects for issue tracking, Codespaces for dev environments, and a full security stack (CodeQL, secret scanning, Dependabot) are all first-class [2]. The honest caveat is timing — these arrived later, layered onto the social graph. The network was the product first; the toolchain grew out of it.

GitLab: the platform

GitLab takes a different bet — not because GitHub lacks the toolchain (it doesn't anymore), but because GitLab built the whole delivery pipeline as one integrated product from day one, not assembled in stages [4]. Its signature is built-in CI/CD — defined by a single .gitlab-ci.yml at the repo root, run on GitLab Runners — and it predates and arguably out-matures GitHub Actions [5]. Issue tracking, merge requests, container registry, package registry, security scanning, environments, and deployments were all there from the start, in one application.

The other thing GitLab is known for is being self-hostable. The entire platform is open-core — I can run it on my own infrastructure, behind my own firewall, with the same UI as the SaaS version [4]. For teams that can't or won't put their code on someone else's cloud (regulated industries, on-prem mandates, air-gapped networks), that's the deciding factor, not a preference.

The comparison I actually use

The model collapses the choice into one trade-off:

Neither is "better." Both are end-to-end these days; the real fork is cloud-first network versus self-hostable platform. For an open-source side project where I want strangers to find and contribute to my work, GitHub is the default because that's where the contributors are. For a team that must run the whole platform on its own hardware — regulated, on-prem, air-gapped — GitLab is the more coherent shape. Bitbucket exists in this same layer too — Atlassian's entry, tightly bound to Jira — but for frontend work the GitHub/GitLab split is what I actually encounter.

How I use this

The habit these notes left me with is a single separation: when something breaks or behaves oddly, I ask is this Git, or is this the host? A rebase conflict, a detached HEAD, a botched merge — that's the engine, and the answer is the same on any host. A missing CI run, a permissions error on a branch, a PR that won't auto-merge, a stale webhook — that's the shell, and the answer is product-specific. Naming which layer I'm actually in saves me from grepping the wrong docs every time.

References

[1] Git, "Git - Distributed Git - Distributed Workflows," Git Documentation. [Online]. Available: https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows

[2] GitHub, "About GitHub," GitHub Docs. [Online]. Available: https://docs.github.com/en/get-started/quickstart/hello-world

[3] GitHub, "Understanding GitHub Actions," GitHub Docs. [Online]. Available: https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions

[4] GitLab, "What is GitLab?," GitLab Documentation. [Online]. Available: https://about.gitlab.com/what-is-gitlab/

[5] GitLab, "GitLab CI/CD," GitLab Documentation. [Online]. Available: https://docs.gitlab.com/ee/ci/