6 ms·

Can someone who has used both this and Gitlab provide an insight on how the experiences differ?

iancarroll 12y ago
GHE requires a lot more resources then GitLab (8GB/4cores min) and anything lower slows it to a crawl, which is a shame. Luckily there's now an AWS image which makes it significantly easier (deploying it now). GHE is very social, GitLab never had that feel for me. Same feature set, really.
- fsiefken 12y ago
  In my experience GitLab runs well on 1 core and 1 GB. Are you also deploying it on a 8GB amazon instance? How important are GHE's social features within an enterprise environment?
  - iancarroll 12y ago
    It is actually locked to instances above m3.large, so I have to redeploy to xlarge or the like. Can't say much about an enterprise environment. The UI is superior IMO.
couchand 12y ago
I've never used GitHub Enterprise, but my experience with GitLab is not so great. If GHE is a beefed-up GitHub, it's probably much cleaner. My major gripe with GitLab is that it's really hard to navigate around. There are lots of links that take you somewhere other than what you'd expect. The landing page for projects is the log, you have to click a tab to see README and file structure, which I've always found clunky. EDIT: also, GitLab's syntax highlighter gets really confused if a search result snippet starts in the middle of a string. Never seen that problem on GitHub, but it could be there, too. Just my 2c.
- codereflection 12y ago
  Our experiences with GitLab have been really positive. GL may not be on par with GHE UX wise, but I don't really feel that this has been an issue for us. Coming from GH or GHE, GL is a little more difficult to navigate, but it's getting better with each release. The thing that probably bugs me the most is the home page for a repository being the activity stream. However, considering that we're saving $25k per year by using GL over GHE, I can happily put up with it. I've never encountered the search issue you describe. We're using the latest GL, perhaps it was a problem with an older version?
  - couchand 12y ago
    Looks like we're still on 7.3.1. I don't see anything in the release notes for more recent versions about syntax highlighting, but they might have snuck something in, or it could be a dependent package change. 25k sure is a lot of money. Then again, can you put a price on the frustration of developers used to working with something better? Maybe.
    - codereflection 12y ago
      25k is for 100 developers, and we actually have more users than that. GHE is really pricey. However, I don't hear complaints about GitLab, probably because everyone was coming from SVN, and they have little experience with GH.
Joe8Bit 12y ago
GHE is (minus the things coming in this v2) the same as using public Github, so in my view is the superior experience to using GL (in most ways I can think of). The issue I have ALWAYS had with GHE isn't with GHE itself but with how organisations use it, there are usually dozens of organisations that make little sense and 1000's of repos that are often empty or abandoned. It becomes a black box of repos that no one really knows the ends of. The real improvements GitHub could make to GHE is improve the discoverability experience, it's UI/UX is inherited from public Github where people work in small(ish) groups on single projects within individual orgs. This, for me, is not the paradigm people employ in GHE.
Osiris 12y ago
Another one to compare it to is Atlassian Stash. It's not as full featured as GitHub but integrates really well with JIRA and Bamboo. It even has some features that GitHub doesn't, like ACLs on branches. It's significantly less expensive that GHE. Currently, my startup is using GitLab. It does the job for the 16 or so developers we have. It has issue tracking, wiki, web hooks, merge requests. Pretty much all the same features as GitHub, but not as clean or pretty.
atbell 12y ago
As someone who's used both Gitlab, Github Enterprise, and Stash in a corporate environment, I have to admit I prefer GHE, for the features it shares with core Github, if nothing else. My only gripe w/ GHE is the lack of branch-based ACLs. If we want to implement a Github Flow (https://guides.github.com/introduction/flow/index.html https://guides.github.com/introduction/flow/index.html) methodology, but also have automatic branch detection and testing in our CI (Jenkins/Bamboo/whatever), we end up having to assign all users the ability to create branches in the given repository (which, in turn, gives them the perms to push to master). I'm actually quite surprised that this hasn't been implemented yet in GHE; I can understand why GH wouldn't have it, but GHE (because of the nature of its user base) really should. That issue aside, the UI in GHE is simply superior to GL and Stash.
- dkuntz2 12y ago
  I'm pretty sure GHE has the ability to disable pushing to the default branch (which is set on a per-project basis, but by default it's master). But I think this is a per-instance setting (unless that's been changed recently). So while everyone would have the ability to push to other branches, they wouldn't be able to touch master outside of pull requests, which I think is what you want anyways.

GHE requires a lot more resources then GitLab (8GB/4cores min) and anything lower slows it to a crawl, which is a shame. Luckily there's now an AWS image which makes it significantly easier (deploying it now). GHE is very social, GitLab never had that feel for me. Same feature set, really.

fsiefken 12y ago
In my experience GitLab runs well on 1 core and 1 GB. Are you also deploying it on a 8GB amazon instance? How important are GHE's social features within an enterprise environment?
- iancarroll 12y ago
  It is actually locked to instances above m3.large, so I have to redeploy to xlarge or the like. Can't say much about an enterprise environment. The UI is superior IMO.

couchand 12y ago

I've never used GitHub Enterprise, but my experience with GitLab is not so great. If GHE is a beefed-up GitHub, it's probably much cleaner. My major gripe with GitLab is that it's really hard to navigate around. There are lots of links that take you somewhere other than what you'd expect. The landing page for projects is the log, you have to click a tab to see README and file structure, which I've always found clunky. EDIT: also, GitLab's syntax highlighter gets really confused if a search result snippet starts in the middle of a string. Never seen that problem on GitHub, but it could be there, too. Just my 2c.

codereflection 12y ago
Our experiences with GitLab have been really positive. GL may not be on par with GHE UX wise, but I don't really feel that this has been an issue for us. Coming from GH or GHE, GL is a little more difficult to navigate, but it's getting better with each release. The thing that probably bugs me the most is the home page for a repository being the activity stream. However, considering that we're saving $25k per year by using GL over GHE, I can happily put up with it. I've never encountered the search issue you describe. We're using the latest GL, perhaps it was a problem with an older version?
- couchand 12y ago
  Looks like we're still on 7.3.1. I don't see anything in the release notes for more recent versions about syntax highlighting, but they might have snuck something in, or it could be a dependent package change. 25k sure is a lot of money. Then again, can you put a price on the frustration of developers used to working with something better? Maybe.
  - codereflection 12y ago
    25k is for 100 developers, and we actually have more users than that. GHE is really pricey. However, I don't hear complaints about GitLab, probably because everyone was coming from SVN, and they have little experience with GH.

Joe8Bit 12y ago

GHE is (minus the things coming in this v2) the same as using public Github, so in my view is the superior experience to using GL (in most ways I can think of). The issue I have ALWAYS had with GHE isn't with GHE itself but with how organisations use it, there are usually dozens of organisations that make little sense and 1000's of repos that are often empty or abandoned. It becomes a black box of repos that no one really knows the ends of. The real improvements GitHub could make to GHE is improve the discoverability experience, it's UI/UX is inherited from public Github where people work in small(ish) groups on single projects within individual orgs. This, for me, is not the paradigm people employ in GHE.

Osiris 12y ago

Another one to compare it to is Atlassian Stash. It's not as full featured as GitHub but integrates really well with JIRA and Bamboo. It even has some features that GitHub doesn't, like ACLs on branches. It's significantly less expensive that GHE. Currently, my startup is using GitLab. It does the job for the 16 or so developers we have. It has issue tracking, wiki, web hooks, merge requests. Pretty much all the same features as GitHub, but not as clean or pretty.

atbell 12y ago

As someone who's used both Gitlab, Github Enterprise, and Stash in a corporate environment, I have to admit I prefer GHE, for the features it shares with core Github, if nothing else. My only gripe w/ GHE is the lack of branch-based ACLs. If we want to implement a Github Flow (https://guides.github.com/introduction/flow/index.html https://guides.github.com/introduction/flow/index.html) methodology, but also have automatic branch detection and testing in our CI (Jenkins/Bamboo/whatever), we end up having to assign all users the ability to create branches in the given repository (which, in turn, gives them the perms to push to master). I'm actually quite surprised that this hasn't been implemented yet in GHE; I can understand why GH wouldn't have it, but GHE (because of the nature of its user base) really should. That issue aside, the UI in GHE is simply superior to GL and Stash.

dkuntz2 12y ago
I'm pretty sure GHE has the ability to disable pushing to the default branch (which is set on a per-project basis, but by default it's master). But I think this is a per-instance setting (unless that's been changed recently). So while everyone would have the ability to push to other branches, they wouldn't be able to touch master outside of pull requests, which I think is what you want anyways.