March 26, 2026/568 words/3 min read

Coming Back to GitHub

Six years on GitLab and a lot of misplaced principle.

Back in 2019 I deleted my GitHub account. Microsoft had recently acquired the platform, wasn't exactly winning people over, and the mood in certain corners of the internet (HN) favoured a principled exodus. I hated the direction things seemed to be heading, so I joined in, migrated everything to GitLab, and felt good about it for about two moments before getting back to whatever I was supposed to be doing.

And then I used GitLab for six years. It's a fine platform. The CI/CD is powerful, the self-hosting was nice even on a cheap DigitalOcean droplet, and for a while it felt like it had more going for it. But the UI is a maze while new features sit in menus you'd never navigate to by instinct, and it stinks of software built by people who stopped caring whether anyone would enjoy using it. Meh. It gets the job done, but it never felt good to use.

So I came back. My opinionated stance aged the way these attitudes tend to, the platform evolved, and I only have so many evenings to spend on tooling.

What won me over was the CLI. gh earned its place immediately. I can create a repo, open a pull request, or check a run's status without leaving the terminal. It sounds like a small thing, but it removes a surprising amount of friction. I started reaching for it instinctively after a few hours. I never did that with GitLab's equivalent.

The rest is more complicated. GitHub Actions is fine, but I keep fighting with the YAML and missing how GitLab handles pipelines. The concepts mostly map, but simple things involve a lot of bullshit. The marketplace is a graveyard of actions last updated in 2021 that you have to use anyway because they're the top result. The runners are also slow, so I route jobs through Blacksmith. The whole integration is a single-line change per job, which I appreciate.

yaml

jobs:
  build:
    runs-on: blacksmith-2vcpu-ubuntu-2404 # was: ubuntu-latest

That one change makes jobs noticeably faster.

Copilot is also everywhere, shoehorned into every surface whether it belongs there or not. I get that it's the product now, and I understand why, but it gives the whole platform a slightly pushy feeling. It's like a shop assistant who follows you around just in case. I use Copilot, I like it, but I don't need it reminding me of that every time I open a PR or write a commit message.

I've supplemented the code review experience with Graphite, which handles stacked PRs properly and has a PR inbox that actually makes sense. The gt CLI is the interesting part. You create branches, commit, and submit PRs without touching the GitHub UI at all.

bash

gt create --all --message "feat: add thing"
gt submit

Stack a second PR on top while the first is in review, push both at once with gt submit --stack, address feedback anywhere in the stack with gt modify, and sync everything back up with gt sync. For personal projects it's overkill, but I use it at work and having the same tool everywhere removes a context switch I didn't realise was bothering me.

The migration itself took the --mirror flag and an evening. I cloned each repo from GitLab and pushed it to GitHub.

bash

git clone --mirror git@gitlab.com:username/repo.git
cd repo.git
git remote add github git@github.com:username/repo.git
git push github --mirror

That moved about ninety repos. The GitLab account is still sitting there with forwarding READMEs in case Claude tries to pull stuff from there. I'll delete it eventually.

GitHub is good and slightly annoying and I'm glad to be back. We'll see.