#GitHub and GitLab

Git is the version control system. GitHub and GitLab are products built on top of it. Nothing on this page is git — it is collaboration workflow, review, CI, and permissions.

#1 · The same ideas, different names

"Pull request" is arguably the worse name. You are requesting that they merge your branch. GitLab's "merge request" describes it accurately. Same object, though.

#2 · The review workflow

flowchart LR
    A["branch<br/>off main"] --> B["commit<br/>locally"]
    B --> C["push<br/>branch"]
    C --> D["open PR / MR"]
    D --> E{"CI passes?"}
    E -->|"no"| B
    E -->|"yes"| F{"review<br/>approved?"}
    F -->|"changes requested"| B
    F -->|"approved"| G["merge<br/>squash / merge / rebase"]
    G --> H["delete branch"]

    classDef gate fill:#fbeee0,stroke:#b15a08,stroke-width:2px
    class E,F gate

A good PR is small. Review quality falls off a cliff past a few hundred lines — reviewers switch from reading to skimming, and skimmed reviews approve bugs. If a change must be large, split it into a stack of small PRs.

Write the description for the reviewer, not the record: what changed, why, and what you want them to look hardest at. "Fixes #123" is not a description.

#3 · Branch protection — what to actually turn on

"Require branches up to date" is the one people skip and then get bitten by. Your PR passed CI against a two-day-old main. Someone else merged an incompatible change. Yours merges green and main breaks. This setting forces a re-run against current main.

#4 · CI side by side

The same pipeline in both systems.

GitHub Actions — .github/workflows/build.yml:

name: Build
on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: npm
      - run: npm ci
      - run: npm test

GitLab CI — .gitlab-ci.yml:

stages: [test]

test:
  stage: test
  image: node:20
  cache:
    key: "$CI_COMMIT_REF_SLUG"
    paths: [node_modules/]
  script:
    - npm ci
    - npm test
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

The clearest structural difference: GitLab CI is container-first — every job declares an image and runs inside it. GitHub Actions is step-and-marketplace-first, where you compose published actions. Neither is better; they reward different habits.

#5 · Choosing

For a public portfolio the answer is GitHub, and it is not close. Not because the product is better, but because that is where people already are.

They interoperate. Both are git, so mirroring one to the other is straightforward, and moving is a push away — the repository is portable even when the CI config and issues are not.

#6 · Making a repo worth finding

Most repositories are invisible, and the reasons are fixable in minutes.

Signal-to-noise is the thing people get wrong. A visitor scans your profile for about fifteen seconds. Forty repos where most are course exercises reads as "student"; six polished ones read as "engineer". Archiving is not deleting — the code stays, it just stops competing for attention.

#7 · Interview questions

#Stop condition

You have this when you can:

1. map PR/MR, Actions/GitLab CI and their config files,
2. name the protections you would enable and why "up to date" matters,
3. write an equivalent pipeline in both systems,
4. choose a platform for a stated goal, and
5. list what makes a repository findable.