8 ms·

Question to current Gitlab users: Why do you use Gitlab instead of Github? What are the killer features that make it worth switching to?

by cj 7y ago

jdcaron 7y ago
It's open source and extensible.
camjohnson26 7y ago
Private Repos by default, not owned by Microsoft, alternative to the established player, built in CI features.
trumbitta2 7y ago
The "Create merge request" (from issue) button. It creates a new branch, with a smart name like 123-my-issue-title, and a new "pull request" for that issue and branch.
- willis936 7y ago
  This sounds similar to Atlassian’s Jira/Bitbucket integration without the jira.
  - ndarwincorn 7y ago
    GitLab's value prop can be more or less summed up as 'everyone else gives you ala carte tools, we give you one that's unified'.
- galacticdessert 7y ago
  Agree. This is indeed a nice tidy workflow. I usually just create a bunch of issues to have a visual representation of what is missing in a project, sort them in a board and then work through them. 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.
- veritas3241 7y ago
  I love that you highlighted this! This is basically a mandatory part of the data team's workflow. Once the MR is open we then spin up a clone of our data warehouse tied to that git branch where all the CI jobs run. I like that it will automatically close the issue too once the MR is merged.
- ndarwincorn 7y ago
  A neat hidden feature (AFAIK, maybe it's buried in documentation) is that if you branch locally and name it [issue number]-branch-name, pushing that branch and opening an MR from it will automatically tie it to [issue number] for the same workflow. Handy for those situations where you started writing code before opening an MR.
config_yml 7y ago
We can self host it, it had (and still has) a great CI (before GitHub had it) and personally it had free private repos before GitHub had it.
showerst 7y ago
It's easily self-hostable.
Townley 7y ago
I want to say it's the freedom to self-host, but really it's the CI. 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.
- jl-gitlab 7y ago
  PM for CI/CD here, thanks so much for your feedback! As much as I'm excited about how much you love the product, we can always do better and I'd love to hear your thoughts. Ping me any time (@jlenny) on any issues that are important to you that would make things better.
  - nwellnhof 7y ago
    Do you have any plans to support matrix builds? I know that they can be emulated with anchors but Travis CI's matrix feature seems a lot nicer.
- danShumway 7y ago
  Agreed. The big thing is that when I'm starting a Node project, Gitlab's CI setup is like 5 lines in a text file and takes me literally about 30 seconds to set up. It's stupidly easy. This has been a huge influence in me doing more automatic testing on personal projects and using merge-based workflows more often.
- bamboozled 7y ago
  How is CircleCI not easy to use? It's honestly the easiest and most feature complete CI system I've ever used.
barkerja 7y ago
I'm not currently using Gitlab anymore, but in the past, it was their CI that won me over. I was always felt left wanting more though because there wasn't a true sense of community/explore. 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.
- mcv 7y ago
  You make Github sound like a social network. A good one, I mean.
  - thanatropism 7y ago
    I've seen some non-technical job applications that have an entry for a Github username.
  - barkerja 7y ago
    Heh, in a way. But I do give a lot of credit to Github for exposing me to some really cool and interesting projects. It does a decent job of knowing what I consider relevant, and surfacing projects/humans that fit the bill.
  - skrebbel 7y ago
    Back when social networks were the new hip thing in startup land and dev tools were not, GitHub ran the tagline "Social Coding".
jakeinspace 7y ago
My employer uses gitlab for most internal projects because of ITAR and other legal restrictions (aerospace). No external hosted services allowed, except obviously for released open source code.
- skrebbel 7y ago
  Wait, the rule says everything must be locally hosted, except if it's open source - then cloud hosted saas is fine? Can you explain the rationale?
  - jakeinspace 7y ago
    If it's open source then necessarily it's been approved by export control. Anything open-sourced obviously can't contain ballistic information which would violate ITAR. But by default, all internal software and documents/documentation related to spacecraft/aircraft are assumed to be sensitive until they've gone through the export control process.
peterwwillis 7y ago
Basically, corporate people are allergic to paid managed services and are afraid of proprietary lock-ins (unless a VP heard it was what all the other VPs were doing). If the open source software has support contracts, and is cheaper, they leap on it. We're actually moving off GitLab onto Github, because it's just... better. Not only because managing it internally sucks, but also Github is just more polished. Still won't pay for GitHub Enterprise though, because we're cheap.
sstangl 7y ago
We switched to Zulip because of a bad experience with Slack holding our message history hostage. At the same time we switched to GitLab because we didn't want a similar issue to arise with our issue tracker. 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.
LennyWhiteJr 7y ago
Can self-host behind an enterprise firewall and get all the benefits of open-source software model within the company without exposing proprietary software projects to the whole world.
- jfim 7y ago
  There's GitHub Enterprise if one wants to self host.
  - markus92 7y ago
    True but being able to test it a bit on a small team is a big help. Migration from CE to EE is relatively easy and demonstrating CE to management helps a lot.
james-skemp 7y ago
At work: our campus has a local instance running, likely for code security issues, and so it integrates with our login service. Integrates nicely with JIRA and TeamCity as well. 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.
tombert 7y ago
I'll admit that I mostly switched because of the MS buyout of Github. 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.
vorpalhex 7y ago
Built in CI that you can run on your own servers trivially, free (private) docker image repo, great support for "teams", even free ones, which allows me to offer my CI boxes to my friends for their side projects. I've had a few vague uptime issues whenever they get a big spike in popularity, but otherwise no complaints.
lucideer 7y ago
Reasons for initially switching to Gitlab: - 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/ 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.
- mcintyre1994 7y ago
  I haven't tried Gitlab sites yet - what makes it better than Github's?
  - lucideer 7y ago
    Note: I haven't yet looked into Github Actions in depth, so if there's GH Pages integration there, some of the below may no longer be true. Github's is tightly coupled to Jekyll, and—more specifically—to this single Gem https://github.com/github/pages-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-pages-part-3-examples-ci/#ssgs-examples https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-page...
neuland 7y ago
We use GitLab because you can self-host it. GitHub is not an option for us, because we must maintain control of our data and source code. So GitHub was never really an option. 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.
- bamboozled 7y ago
  https://enterprise.github.com/faq https://enterprise.github.com/faq
  - sancha_ 7y ago
    I believe self-hosting is a pretty new option. Gitlab always had it afaik.
    - trumbitta2 7y ago
      Self-hosted GitHub enterprise exists since like 5 years ago.
  - orf 7y ago
    Yes, a product that is twice as expensive as Gitlab and has like 10% of the features.
    - irq11 7y ago
      So you (like 95% of the commenters here) prefer Gitlab be cause it’s cheap. 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.
sashk 7y ago
We need on-premise installation of Gitlab. Github enterprise was too expensive for a small team. Integrated CI/CD is a plus.
LanceH 7y ago
I first used it for a free repo. 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.
jeena 7y ago
Self hosting is super easy with docker https://docs.gitlab.com/omnibus/docker/ https://docs.gitlab.com/omnibus/docker/
the_jeremy 7y ago
Gitlab-CI is easy(ish) to learn and extremely well documented. The built-in container registry and artifact repo are super useful.
Merad 7y ago
Our devops team loves Gitlab pipelines and pushed the decision through. If you're looking for a "killer feature" on Gitlab, pipelines is probably it. 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...
- emilycook 7y ago
  Hi! GitLab employee, thank you for your feedback! I'm going to distribute it to the correct teams, but I wanted to respond to a few points: > 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 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/squash_and_merge.html#overview https://docs.gitlab.com/ee/user/project/merge_requests/squas... The original issue around this: https://gitlab.com/gitlab-org/gitlab-foss/issues/47149 https://gitlab.com/gitlab-org/gitlab-foss/issues/47149

Question to current Gitlab users: Why do you use Gitlab instead of Github? What are the killer features that make it worth switching to?

by cj 7y ago

Question to current Gitlab users: Why do you use Gitlab instead of Github? What are the killer features that make it worth switching to?

jdcaron 7y ago

It's open source and extensible.

camjohnson26 7y ago

Private Repos by default, not owned by Microsoft, alternative to the established player, built in CI features.

trumbitta2 7y ago

The "Create merge request" (from issue) button. It creates a new branch, with a smart name like 123-my-issue-title, and a new "pull request" for that issue and branch.

willis936 7y ago
This sounds similar to Atlassian’s Jira/Bitbucket integration without the jira.
- ndarwincorn 7y ago
  GitLab's value prop can be more or less summed up as 'everyone else gives you ala carte tools, we give you one that's unified'.
galacticdessert 7y ago
Agree. This is indeed a nice tidy workflow. I usually just create a bunch of issues to have a visual representation of what is missing in a project, sort them in a board and then work through them. 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.
veritas3241 7y ago
I love that you highlighted this! This is basically a mandatory part of the data team's workflow. Once the MR is open we then spin up a clone of our data warehouse tied to that git branch where all the CI jobs run. I like that it will automatically close the issue too once the MR is merged.
ndarwincorn 7y ago
A neat hidden feature (AFAIK, maybe it's buried in documentation) is that if you branch locally and name it [issue number]-branch-name, pushing that branch and opening an MR from it will automatically tie it to [issue number] for the same workflow. Handy for those situations where you started writing code before opening an MR.

config_yml 7y ago

We can self host it, it had (and still has) a great CI (before GitHub had it) and personally it had free private repos before GitHub had it.

showerst 7y ago

It's easily self-hostable.

Townley 7y ago

I want to say it's the freedom to self-host, but really it's the CI. 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.

jl-gitlab 7y ago
PM for CI/CD here, thanks so much for your feedback! As much as I'm excited about how much you love the product, we can always do better and I'd love to hear your thoughts. Ping me any time (@jlenny) on any issues that are important to you that would make things better.
- nwellnhof 7y ago
  Do you have any plans to support matrix builds? I know that they can be emulated with anchors but Travis CI's matrix feature seems a lot nicer.
danShumway 7y ago
Agreed. The big thing is that when I'm starting a Node project, Gitlab's CI setup is like 5 lines in a text file and takes me literally about 30 seconds to set up. It's stupidly easy. This has been a huge influence in me doing more automatic testing on personal projects and using merge-based workflows more often.
bamboozled 7y ago
How is CircleCI not easy to use? It's honestly the easiest and most feature complete CI system I've ever used.

barkerja 7y ago

I'm not currently using Gitlab anymore, but in the past, it was their CI that won me over. I was always felt left wanting more though because there wasn't a true sense of community/explore. 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.

mcv 7y ago
You make Github sound like a social network. A good one, I mean.
- thanatropism 7y ago
  I've seen some non-technical job applications that have an entry for a Github username.
- barkerja 7y ago
  Heh, in a way. But I do give a lot of credit to Github for exposing me to some really cool and interesting projects. It does a decent job of knowing what I consider relevant, and surfacing projects/humans that fit the bill.
- skrebbel 7y ago
  Back when social networks were the new hip thing in startup land and dev tools were not, GitHub ran the tagline "Social Coding".

jakeinspace 7y ago

My employer uses gitlab for most internal projects because of ITAR and other legal restrictions (aerospace). No external hosted services allowed, except obviously for released open source code.

skrebbel 7y ago
Wait, the rule says everything must be locally hosted, except if it's open source - then cloud hosted saas is fine? Can you explain the rationale?
- jakeinspace 7y ago
  If it's open source then necessarily it's been approved by export control. Anything open-sourced obviously can't contain ballistic information which would violate ITAR. But by default, all internal software and documents/documentation related to spacecraft/aircraft are assumed to be sensitive until they've gone through the export control process.

peterwwillis 7y ago

Basically, corporate people are allergic to paid managed services and are afraid of proprietary lock-ins (unless a VP heard it was what all the other VPs were doing). If the open source software has support contracts, and is cheaper, they leap on it. We're actually moving off GitLab onto Github, because it's just... better. Not only because managing it internally sucks, but also Github is just more polished. Still won't pay for GitHub Enterprise though, because we're cheap.

sstangl 7y ago

We switched to Zulip because of a bad experience with Slack holding our message history hostage. At the same time we switched to GitLab because we didn't want a similar issue to arise with our issue tracker. 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.

LennyWhiteJr 7y ago

Can self-host behind an enterprise firewall and get all the benefits of open-source software model within the company without exposing proprietary software projects to the whole world.

jfim 7y ago
There's GitHub Enterprise if one wants to self host.
- markus92 7y ago
  True but being able to test it a bit on a small team is a big help. Migration from CE to EE is relatively easy and demonstrating CE to management helps a lot.

james-skemp 7y ago

At work: our campus has a local instance running, likely for code security issues, and so it integrates with our login service. Integrates nicely with JIRA and TeamCity as well. 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.

tombert 7y ago

I'll admit that I mostly switched because of the MS buyout of Github. 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.

vorpalhex 7y ago

Built in CI that you can run on your own servers trivially, free (private) docker image repo, great support for "teams", even free ones, which allows me to offer my CI boxes to my friends for their side projects. I've had a few vague uptime issues whenever they get a big spike in popularity, but otherwise no complaints.

lucideer 7y ago

Reasons for initially switching to Gitlab: - 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/ 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.

mcintyre1994 7y ago
I haven't tried Gitlab sites yet - what makes it better than Github's?
- lucideer 7y ago
  Note: I haven't yet looked into Github Actions in depth, so if there's GH Pages integration there, some of the below may no longer be true. Github's is tightly coupled to Jekyll, and—more specifically—to this single Gem https://github.com/github/pages-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-pages-part-3-examples-ci/#ssgs-examples https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-page...

neuland 7y ago

We use GitLab because you can self-host it. GitHub is not an option for us, because we must maintain control of our data and source code. So GitHub was never really an option. 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.

bamboozled 7y ago
https://enterprise.github.com/faq https://enterprise.github.com/faq
- sancha_ 7y ago
  I believe self-hosting is a pretty new option. Gitlab always had it afaik.
  - trumbitta2 7y ago
    Self-hosted GitHub enterprise exists since like 5 years ago.
- orf 7y ago
  Yes, a product that is twice as expensive as Gitlab and has like 10% of the features.
  - irq11 7y ago
    So you (like 95% of the commenters here) prefer Gitlab be cause it’s cheap. 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.

sashk 7y ago

We need on-premise installation of Gitlab. Github enterprise was too expensive for a small team. Integrated CI/CD is a plus.

LanceH 7y ago

I first used it for a free repo. 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.

jeena 7y ago

Self hosting is super easy with docker https://docs.gitlab.com/omnibus/docker/ https://docs.gitlab.com/omnibus/docker/

the_jeremy 7y ago

Gitlab-CI is easy(ish) to learn and extremely well documented. The built-in container registry and artifact repo are super useful.

Merad 7y ago

Our devops team loves Gitlab pipelines and pushed the decision through. If you're looking for a "killer feature" on Gitlab, pipelines is probably it. 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...

emilycook 7y ago
Hi! GitLab employee, thank you for your feedback! I'm going to distribute it to the correct teams, but I wanted to respond to a few points: > 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 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/squash_and_merge.html#overview https://docs.gitlab.com/ee/user/project/merge_requests/squas... The original issue around this: https://gitlab.com/gitlab-org/gitlab-foss/issues/47149 https://gitlab.com/gitlab-org/gitlab-foss/issues/47149