Question to current Gitlab users: Why do you use Gitlab instead of Github? What are the killer features that make it worth switching to?
It was non-trivial to get the issues out of GitHub, and we lost metadata in the process. But now we're on a platform that has an "Export Everything" button, and in the worst case we can self-host our own data.
Although that's why we moved, and we didn't know about it at the time, "Service Desk" became a killer feature. That lets users file issues directly into our GitLab issue tracker by sending an email -- no account setup necessary. The majority of our users are non-technical and this has made it much easier for them to communicate with us.
- Pricing structure made much more sense than Github's at the time. I would've been willing to pay for Github, but their pricing for private repos (now unlimited on the free plan) scaled steeply for any reasonable number.
- In addition to private repos, their free plan still offers many features that Github's free plan lacks, and their paid plans have many more features again than Github (Github focuses on polish, while Gitlab bundles the kitchen sink). While they may lack polish, some of these features are genuinely useful. Particularly around CI. Github's Actions API is an embarassingly recent addition.
- Gitlab Sites: their answer to Github Sites is an underadvertised and wickedly powerful feature. Github Sites really pales in comparison.
Reasons for staying:
- Responsive / active / communicative support team. Getting talking to Gitlab staff is incredibly easy.
- Proactively/playfully innovative culture, evident on tickets and MRs throughout their projects. I also really liked their approach to GithubLab: https://hub.gitlab.com/
- Transparent process. Finding out what's cooking in Github is frustratingly impossible, and why Github holds off supporting seemingly obvious things for eternity is just odd.
- The warm fuzzy feeling of storing my code on an open-source stack.
Reasons for wanting to leave:
- Stability and site performance have always been and continue to be abysmal. This seems to be a result of a reasonably good team being lost in a sea of complexity in a platform on which new features are prioritised over a simplified architecture. They do seem to spend a lot of time working on polish and performance, but never actually managing to achieve either of these things.
Github's is tightly coupled to Jekyll, and—more specifically—to this single Gem https://github.com/github/pages-gem Also, this might have changed, but last time I interacted with it, it lacked any real control over your source repo structure: there's some arcane rules about either giving it a certain name under a certain GH org, or using a specifically named branch (`gh-pages`).
Github were also pretty lax about adding HTTPS support to custom domains their Pages service.
In comparison, GL pages allows:
- using any SSG[0]
- writing your own custom SSG (even integrated/including in your repo itself)
- automatic LetsEncrypt renewal for custom domains
- out-of-repo secrets management for any tasks within your SSG build/deploy steps
[0] https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-page...
Really, is this new? I wasn't aware of it.
I will add that, while this is subjective, I also think that Gitlab has a nicer interface and is better organized. On top of everything parent mentions, there's a lot of subtle stuff like this that makes me stay.
But we'd likely be using GitLab even if we didn't have this limitation. There's a bunch of features that make GitLab better for our specific team / situation. From my personal experience, GitLab CI is better than CI options available on GitHub. We use gitflow (ie. feature branches in the same repo), rather than pull requests. And it seems like GitLab supports this flow well.
I also tend to like GitLab issues much better than GitHub. The time tracking feature in EE is really useful (not sure if GitHub uses this). And issue boards across projects is also a very popular thing where I'm at, because we have lots of repos, rather than fewer big ones.
We also heavily use the deployment / environment features and built-in prometheus.
Bodes well for the business model. Commodity pricing only works when the market gets bigger as the price goes down. Otherwise, it’s just a race to the bottom.
It's better than paying for 10 individual tools that don't work well together.
Throwing a .gitlab-ci.yml file into my repo is by far the easiest way to get CI/CD incorporated into a product. The configuration of test runners (or lack thereof) is both a breeze and extremely powerful.
I'm not even talking about the auto-devops thing that I haven't tried; writing your own gitlab-ci file worked in frictionless ways that CircleCI, Travis, and (especially) Jenkins didn't.
This has been a huge influence in me doing more automatic testing on personal projects and using merge-based workflows more often.
It creates a new branch, with a smart name like 123-my-issue-title, and a new "pull request" for that issue and branch.
Issues are good place for asking input and feedback, and also help in keeping feature branches focused and short lived. Definitely my favorite git workflow.
Handy for those situations where you started writing code before opening an MR.
If there's one thing I value most about Github today it's the ability to easily discover new projects and human beings; and Github helps tremendously with that whereas Gitlab I feel like you end up fighting the system to discover new and interesting things and people.
As a developer I don't think there's a huge difference, especially since we don't use the issue tracking or wiki stuff (we're all in Jira/Confluence). My main complaint about Gitlab is that there are a lot of places where the UI is rough around the edges (lots of pages lack or have very minimal search/sort options) or has outright bad UX, as well as lacking some features that feel pretty basic to me.
My main complaints about Gitlab at the moment:
* Lack of search/sort, as mentioned above
* We created teams in Gitlab to mirror our scrum teams... when you look at the team list in Gitlab, it shows everyone who has access to the team, which is our whole damned Gitlab account. The only way to find the actual team members is to scroll down the list looking for users with a delete icon by their name (which removes them from the team).
* If you want to set a required number of approvals on merge requests, you also have to set the list of reviewers. I wanted to set two required approvers but let the devs assign who (normally their team)... no can do.
* Poor support for making merge requests build the result the merge (instead of just the branch). We've tried setting it up a couple of times, but usually end up with MR's hung because Gitlab doesn't firing the right builds and end up having to turn it off.
* If you have the server squash commits when closing a MR there's no way to set the commit message in advance; you have to type in the message just before you click the merge button. This wouldn't be an issue if it defaulted to using the MR description as the commit message, but it doesn't do that either...
> when you look at the team list in Gitlab, it shows everyone who has access to the team
This has been an ongoing issue for a while, but a fix is currently scheduled for 12.4: https://gitlab.com/gitlab-org/gitlab-foss/issues/44958
> server squashing commits
You don't have to provide a custom squash message, and the default behavior will be either (a) taken from the first multi-line commit message in the merge, or (b) the merge request’s title if no multi-line commit message is found.
Documentation: https://docs.gitlab.com/ee/user/project/merge_requests/squas...
The original issue around this: https://gitlab.com/gitlab-org/gitlab-foss/issues/47149
Re squash commits: as a MR author what I want is the ability to set the commit message in advance (even if it's just a check box to say "use the MR title and description". Using a commit message is a sane default behavior, but not extremely helpful most of the time (IMO). If I'm going to rely on it for the message in my squashed commit I'm going to have to remember to check my branch history, and most of the time I'll probably have to do an interactive rebase to clean things up and ensure Gitlab grabs the correct commit message. It also negates the value of "squash on the server" - if I need to do an interactive rebase anyway, it only requires about 30 seconds extra to just do the squash myself.
The issue wasn't specifically because I have any particular issues with MS, but more due to the fact that Github can be bought. I felt like the epicenter of open-source software should be built on something open-source, especially when that open-source thing has nearly 1-to-1 feature parity.
I know Gitlab has a fair amount of proprietary stuff, but at least I can build my own Gitlab server for free on my own hardware if I decide that I really hate their free hosting.
Personally: I leverage both GitHub and GitLab. GitHub has the greater community, but GitLab Pages is far easier to use. So my workflow process is to have GitLab mirror GitHub repos.
Free private repos was a feature of GitLab, but once GitHub implemented that it just resulted in me dropping the paid tier I was on.
So I guess GitLab Pages is the feature I use it for the most.
I've had a few vague uptime issues whenever they get a big spike in popularity, but otherwise no complaints.
After using it, it just had a better vibe. Features seem similar enough for me, but it seems like Gitlab just lined up with what I want more than Github.
An example of this is the default page when I log in. On Github I'm given my activity feed -- which 90% of the time is absolute noise. Gitlab presents me with a list of repos, which is typically what I want.