I’ve been becoming more and more enamored with GitLab.
I’ve always used GitHub for personal projects but, despite it being the de facto standard for developers looking for a place to keep their repositories, I decided to move to GitLab as the primary location for storing my projects and hosting my static website.
Why not GitHub
GitHub is sleek, beloved by many and the social network for developers around the world. That being said I’ve always been niggled by a couple of things;
Firstly GitHub doesn’t allow private repositories for free users. For me that means I can’t use it for all my projects. I’m just not always comfortable making projects immediately public, even if I intend them to be open source in the end.
For one thing, I don’t want to clutter the web with half-baked abandoned projects that will confuse rather than help fellow travellers. Secondly, a curse of GitHub‘s success is that it’s become part of a developer’s CV, and I don’t want to be judged on the basis of some unloved hacky script, suited only for my needs, I wrote 5 years ago.
Also, while GitHub makes many fine contributions to the open-source community, it isn’t open source itself. It’s only a little niggle, but niggle me it does.
Free Private Repos
A free account on the public GitLab has unlimited free private repos, so I can wait until my project is ready before publicising it.
It has all the features of GitHub and more. Where the feature exists on both platforms I often prefer the GitLab equivalent.
I love the issue board system and have been using it for keeping track of the masses of projects and ideas I always have floating around.
My experience with GitHub CI has mostly been via Travis CI. Which like GitHub is free, but not open source. The integration with GitHub is not bad, but it doesn’t feel as well integrated as GitLab‘s solution.
GitLab provides built in CI for free, which not only works on private projects but can also use self-hosted runners and integrates well with Kubernetes clusters.
Easy To Grow
The GitLab CI runners can also be run locally for testing the CI scripts, but also in a more permanent fashion if you want to use your own pool rather than the public one.
I like the idea that I can start with a very capable free service and then expand either by throwing money at the problem by upgraded my account, or by hosting additional stuff at home, be it just additional runners, or a whole GitLab CE instance.
I feel less locked in.
They’re all about distributed remote working
I’m a remote working fanatic and GitLab seem to be a stellar example of building a completely distributed organisation and in doing so achieving far more than if they’d collocated.
See this article for more information on how they did it and why it works so well.
To me, if you’re a company that claims to be the next big thing in collaboration, and you’re not working with a distributed team then you don’t really believe in your product.
GitLab seem to understand the opportunities and the risks of fully remote working. They trust in their team and their tech to make it work better than collocating could. Kudos!
Problems with GitLab
All the extra functionality, and some design decisions, also make the interface a bit gnarlier and it can be hard to find what you’re looking for sometimes.
Finally, there’s the popularity factor. GitHub is king and it’s the first place people look for projects and developer profiles. As a result I feel the need to maintain a presence there for promoting myself any projects I’m working on, and to contribute to the other projects based there. GitLab has a hard time ahead of itself to take the crown.
For me though, this is a small price to pay for the additional functionality I get from GitLab.
I’ve already moved most of my stuff, but might write a follow up on how especially as an update to the original article on how I built this site.
Then again it’s been over a year since my last post. So who knows!Go Top