GitHub got bought by Microsoft. GitLab kept shipping features. According to joshtronic.com, that's the rough shape of the past year for a developer who moved all his repositories from one to the other — and who also ran the same speed comparison he ran a year ago.
The headline result from this year's run: GitLab was still slower than GitHub on every basic git operation tested. The author moved anyway.
What happened:
- GitHub was acquired by Microsoft in the intervening year.
- The author moved all personal projects to GitLab.
- This year's speed test ran git clone, pull, and push 10 times each.
- GitHub beat GitLab on every operation, as in last year's test.
- GitLab's built-in CI/CD was the deciding factor.
Why GitLab won despite being slower
The move wasn't about speed. The author lays out two reasons, and they're both about workflow, not throughput.
First, GitLab's organization model. Repositories can be nested in groups, and groups can be nested in groups. The author uses a top-level group for client work, then sub-groups per client. GitHub offers organizations, but achieving the same nesting costs $25 per month per organization. For a developer juggling multiple side projects, that's a real bill.
Second, GitLab's built-in CI/CD. The author runs continuous integration and deployment without bolting on third-party services or wiring up a chatbot. The free tier includes enough CI/CD to cover the workload. The cost savings over stitching together external services is significant.
How the speed test was done
The post reuses the methodology from the previous year's comparison. The operations tested were git clone, git pull, and git push. Each operation was run ten times. The reported number is the average of the totals from the time command.
The author notes that he isn't 100% sure which part of the time output he used last year, so direct year-over-year comparison is loose. The methodology is consistent within this year's run.
The published averages, 10 runs each, came out like this:
| Operation | GitHub | GitLab |
|---|---|---|
| git clone | 0.9413s | 1.9053s |
| git pull | 0.9777s | 1.7477s |
| git push | 0.9995s | 2.0255s |
In plain terms, GitLab roughly doubled the wall-clock time for every operation measured. The author flags that the gap is still "almost trivial" in absolute terms — we're talking about one to two extra seconds per command.
Our analysis
The interesting analytical angle isn't the speed gap — it's the trade-off the author made. GitLab costs nothing and replaces a stack of third-party services. GitHub is faster and cheaper if you only need a remote. The author picked the option that removes more moving parts, even at the cost of slower git operations.
There's also a quiet Microsoft question hiding in the post. The acquisition closed during the year in question, and the author moved his repositories anyway — explicitly not because of the sale. That's a useful data point for anyone weighing the same choice. Plenty of developers moved for reasons that have nothing to do with the corporate parent.
The author's own framing matters: he calls GitLab's free CI/CD tier "quite generous" and notes the tier is "more than sufficient" for his needs. That word — sufficient — is doing real work. GitLab didn't have to be best-in-class on CI. It just had to be good enough that he could drop the third-party stack.
What to watch: GitLab's CI/CD feature parity with the third-party services it replaces. The bigger GitLab's built-in CI becomes, the harder it is for GitHub to win on workflow features alone.
A practical scenario
Say you're running a small side project and your daily loop is commit, push, wait for CI, deploy. With GitHub, you're probably wiring up something like an external CI service and a separate deploy target. With GitLab, the same loop lives inside one product. You lose a second or two per git operation and gain the absence of several SaaS subscriptions and one chatbot configuration.
For a single developer, that trade-off is usually worth it. For a team of fifty, the math gets more interesting and depends entirely on what you already pay for.
Bottom line
GitHub is faster on raw git operations. GitLab is faster on workflow consolidation. The author picked workflow. Plenty of other developers reached the same conclusion, with or without a Microsoft acquisition in the background.
Key takeaways
- GitLab remains slower than GitHub on clone, pull, and push, by roughly a two-to-one margin.
- The author moved to GitLab for nested groups and built-in CI/CD, not for git speed.
- GitHub's nested-organization equivalent costs about $25 per month per organization.
- GitLab's free tier replaces several third-party CI and deployment services.
- The Microsoft acquisition of GitHub was not a factor in the author's decision to switch.
Frequently asked questions
Is GitLab still slower than GitHub?
Yes. In the most recent test GitLab took noticeably longer on every operation measured, as in the previous year's comparison.
Why did the author move to GitLab despite the slower git speed?
GitLab offers a deeper organization model and a free built-in CI/CD tier, which replaced several paid third-party services in the author's workflow.
How much does GitHub's equivalent nested organization cost?
About $25 per month per organization, per the article.
Did the Microsoft acquisition of GitHub influence the switch?
No. The article states the move was driven by workflow features, not by GitHub's new corporate parent.
Does the year-over-year speed comparison hold up?
Loosely. The author notes uncertainty about which portion of the time output was used in last year's test, so direct year-over-year numbers should be treated as approximate.