GitHub, GitLab & Bitbucket

Git is the tool that tracks your code history on your own machine. But teams need a shared place to store that code online, review each other’s changes, and run automation. That is what hosted Git platforms do. GitHub, GitLab, and Bitbucket all host your Git repositories in the cloud and then layer extra features on top — pull requests, issue tracking, CI/CD pipelines, and package registries. This page explains what each one adds, how they differ, and how to pick the right one for your project.

First, some quick definitions. A repository (or “repo”) is a project folder that Git tracks. A remote is a copy of your repo hosted somewhere else — these platforms host that remote for you. CI/CD means Continuous Integration / Continuous Deployment: automation that builds, tests, and deploys your code every time you push. A pull request (PR), called a merge request (MR) on GitLab, is a request to merge one branch into another where teammates review the code first. A registry is a storage area for build artifacts like Docker images or npm packages.

What the platforms add on top of Git

Plain Git only gives you version control. The platforms wrap it with collaboration and automation features you would otherwise have to build yourself:

Hosting — a central, backed-up remote everyone on the team pushes to and pulls from.
Pull/merge requests — a web UI for proposing, discussing, and reviewing changes line by line.
Issue tracking — a built-in bug and task tracker linked to your code and commits.
CI/CD — pipelines that run on every push (tests, linting, builds, deploys).
Access control — who can read, write, or administer each repo, with branch protection.
Registries — somewhere to publish Docker images, npm/Maven/PyPI packages, and releases.
Wikis and pages — documentation and static sites hosted next to the code.

Gotcha: the platform is not Git. If your account gets locked or the service has an outage, your full history still lives in every clone on every developer’s laptop. That is the beauty of Git being distributed — but it also means you should keep at least one extra remote or backup so the platform is never a single point of failure.

GitHub, GitLab, and Bitbucket compared

Feature	GitHub	GitLab	Bitbucket
Owner	Microsoft	GitLab Inc.	Atlassian
Built-in CI/CD	GitHub Actions	GitLab CI/CD	Bitbucket Pipelines
Code review unit	Pull request (PR)	Merge request (MR)	Pull request (PR)
Free private repos	Yes	Yes	Yes (small teams)
Self-host option	GitHub Enterprise Server	GitLab self-managed (Community Edition is free, open source)	Bitbucket Data Center
Container/package registry	Yes	Yes (strong)	Limited
Built-in issue tracker	Yes	Yes (full boards)	Basic (deep Jira integration instead)
Best known for	Largest open-source community, Actions marketplace	All-in-one DevOps in one app	Tight Atlassian/Jira integration

The headline difference is philosophy. GitLab wants to be one application for the entire DevOps lifecycle — code, CI/CD, security scanning, registries, and project management in a single tool. GitHub is the home of open source and has the biggest ecosystem, the largest marketplace of reusable automation, and the most third-party integrations. Bitbucket is the natural choice if your team already lives in Atlassian tools like Jira and Confluence.

GitLab’s built-in CI vs GitHub Actions

Both run automation on every push, but they are configured differently.

GitLab CI/CD has been built into GitLab from early on. You add a single file called .gitlab-ci.yml to the root of your repo. GitLab runs the jobs on machines called runners (you can use GitLab’s shared runners or install your own).

# .gitlab-ci.yml — runs tests on every push
stages:
  - test

run-tests:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm test

GitHub Actions is GitHub’s automation system. You put one or more YAML files inside a .github/workflows/ folder. Its strength is the marketplace — thousands of ready-made, reusable steps called “actions” that you drop into a workflow.

# .github/workflows/ci.yml — runs tests on every push
name: CI
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
      - run: npm ci
      - run: npm test

When to use which: choose GitLab CI if you want one tool for everything and value its mature, batteries-included pipelines (built-in container registry, security scanning, and review apps). Choose GitHub Actions if you are already on GitHub and want the huge marketplace of pre-built actions and the largest community to copy patterns from.

Connecting your repo from Ubuntu

The workflow is the same on all three platforms: create a repo in the web UI, then point your local repo at it. The most secure method is SSH (an encrypted key pair so you never type a password). Generate a key on your Ubuntu machine:

ssh-keygen -t ed25519 -C "[email protected]"
cat ~/.ssh/id_ed25519.pub

Output:

Generating public/private ed25519 key pair.
Your identification has been saved in /home/you/.ssh/id_ed25519
Your public key has been saved in /home/you/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... [email protected]

Copy that public key into the platform (GitHub: Settings → SSH and GPG keys; GitLab: Preferences → SSH Keys; Bitbucket: Personal settings → SSH keys). Then add the remote and push:

git remote add origin [email protected]:acme/my-app.git
git push -u origin main

Output:

Enumerating objects: 12, done.
Writing objects: 100% (12/12), 1.84 KiB | 1.84 MiB/s, done.
To github.com:acme/my-app.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Security tip: never paste your private key (id_ed25519, with no .pub) anywhere. Only the .pub file goes into the platform. And avoid storing a plain-text password in your Git remote URL — use SSH keys or a short-lived personal access token instead.

How to choose for a project

Your situation	Best pick
Open-source project, want contributors and visibility	GitHub
Want one tool for code + CI + registry + security, possibly self-hosted free	GitLab
Team already uses Jira / Confluence	Bitbucket
Need the biggest marketplace of ready-made automation	GitHub
Strict data residency / must run on your own servers	GitLab self-managed (free CE)

For most new teams in 2026, GitHub is the safe default thanks to its ecosystem and Actions. Pick GitLab when you want an all-in-one DevOps platform or free self-hosting, and Bitbucket when you are committed to the Atlassian suite.

Best Practices

Use SSH keys or short-lived tokens for authentication — never embed passwords in remote URLs.
Protect main with branch protection: require passing CI and at least one approved review before merge.
Keep CI config (.gitlab-ci.yml or .github/workflows/) in the repo so the pipeline is versioned with the code.
Enable required status checks so broken code can never merge into your default branch.
Add a second remote or scheduled backup so the platform is never your only copy.
Pin action/runner versions (e.g. actions/checkout@v4) for reproducible, predictable builds.
Use the built-in issue tracker and link commits to issues (e.g. Fixes #42) to keep history traceable.