We use and love Atlassian Stash (https://www.atlassian.com/software/stash), it's excellent for code reviews. The diff view options and commenting make it easy to create pull requests, get feedback and eventually merge code into the master branch. (Per branch permissions are awesome too.)
Long time ago we also assessed GitLab and found it usable but not quite there yet for production use. Though it looks nicer now.
I use Stash and I'm quite satisfied with it. The ability to create branches from "inside" JIRA and then check out in the desktop from Stash is good for newcomers to Git.
Plus the ability to prevent pull requests from being merged without X approvals, at least one successful Bamboo build etc. It's all very well integrated and polished.
I'm just waiting on rebase instead of merge for pull requests.
I love the approval merging too, also the locking of branches (e.g. only X people have the ability to commit to master, everyone else has to have a PR reviewed and merged).
I wish it allowed comments in more places than just PRs, but it's been pretty great so far.
The only thing that puts me off Stash is that I'm a part time JIRA, Fisheye, Crucible admin (on site ~ 250 users) and my word both those things make me cry at least once a week with problems. If it's not dealing with the licensing hell and the tears of management when another $32k pisses down the drain on maintenance (mafia style protection) it's dealing with memory leaks, crashes and constant performance bottlenecks. And we run this on a cluster of three high end 8 Core/32Gb RAM/SAS disk HP machines...
I couldn't face Stash after that.
Edit: Atlassian support are excellent but we have to bug them too often with entire sites down (workflow consistency issues fucking the entire JIRA instance which happens at least once a month) for the product to be considered quality.
We've been using Stash as well and I'm, for the most part, quite pleased with it. My biggest initial problem was a lack of GitHub style, convenience feature. In the last couple updates, they've filled in the biggest feature gaps and demonstrated they know what they're customers want.
I am using Stash also. Love the new side-by-side diff. We switched from Gitlab to Stash few months ago. Mainly because Stash upgrade was way easier than Gitlab at that time.
Thanks for the feedback (and others) on stash. Right now we're down to choosing between Stash and a couple others, and it seems to be the best choice for the team.
Hey anything is better than SVN which is what we use now!
On the Admin side it has been easy to get up and running for testing, the upgrades are pretty painless and come on a time based release cycle. The docs are decent and there is a rest api and the company has been very responsive to tickets we file. And it is _significantly_ cheaper than github:fi.
On the user side it hits all of the big items and the interface is useable. It doesn't have some features like GitHub's image diff or gh_pages support, but for many things there are Stash plugins that either exists or you can write. And they provide an easy way to not leak internal url's while using gravatar (http://benjamin-meyer.blogspot.com/2014/03/how-to-stop-leaki...)
The biggest downside I have at this point would be that out of the box the permissions model is not as rich/robust as gitolite. Although most Git frontend servers are no where near as rich as gitolite.
Developers will love it. For what it's worth Stash fits perfectly in our review process where anyone can be assigned to review and comment on code. The pull request diff explorer makes it super easy to track which files have been reviewed already and contain comments. It really has increased our overall effiency and shared knowledge as a team of seniors and juniors.
Off topic: This is the first I've seen of BitNami and it looks great, especially the cloud hosting app. I'd switch from our current system (mainly AWS tools and shell scripts for app deployment) in a heartbeat but there's no way I can justify $599/mo for 10-15 servers. I'm surprised you don't use a PAYG pricing model like most of the IaaS providers out there..
Thanks for the feedback. We're working on refining our pricing. If you want to use the service, shoot me an email to erica at bitnami and we'll work something out.
This will make GitLab an easier choice in the future. If you're looking for a lighter choice Gitbucket is really nice: https://github.com/takezoe/gitbucket
Would you folks ever consider releasing a non-omnibus package? I'm averse to packages which include their own dependencies, but have developers who would benefit greatly from GitLab otherwise.
Of course it's released right after I get everything to play nice in an Ansible role... But this will help with adoption immensely; I'm sure many people have dropped GitLab simply because installation and upgrades were a nightmare (especially to non-native Rubyists).
I can attest to this as well. We installed Gitlab about 2 months ago, and a notable upgrade came out recently (I'm gapping on version numbers) and I was able to update our in-house server with very little effort by following the great instructions.
I know Ruby relatively well but I'm by no means a "pro", and I had no issues.
We've been using Gitlab side by side with Github for the past few months. In general it's a very nice replacement, but one thing I've been fighting with lately is code review capabilities.
The problem I've been having is when I go to a commit, in Github I'll be able to see what's changed (the diffs), but in Gitlab I often get "diff too big and not shown for perf reasons" or suchlike. This inability to reliably view diffs makes me wonder how we're going to do code review on projects hosted on Gitlab.
Does anyone else have experience with this, or any workarounds?
We too find the code review system in GitLab (and GitHub for that matter) to be lacking. We add the repository to Crucible and it automatically indexes the commits. We then do code reviews on GitLab branches there. Yes, Crucible is commercial but it's far above reviewboard, gerrit, etc.
The main workaround is to keep your commits small. If you run your own GitLab server your can also tune the constants that affect this behavior. If you have a good use-case feel free to send a merge request to increase them so they get better for everyone.
Aha. I'll have a chat with the guy who administrates our install about tweaking the constants.
The example I had from this morning was quite a large diff (47 changed files). I'd rather have a large page load time and be able to see the diffs though.
We just released GitLab 6.8 minutes ago https://www.gitlab.com/2014/04/22/gitlab-6-dot-8-released/ The main new feature of this release is protection against force pushes. Other changes include improvements to mentioning in comments, Merge Request UI improvements and new API features.
I am working on a Brazilian public sector project, and since we only use open source alternatives running on our own servers (for security reasons), we chose Gitlab. It works nicely. The earlier versions consumed a lot of memory, but recently that's getting better. Would not recommend a too lightweight server, though.
Whenever I see things like this ("like X, but written in a different language"), I can't help but think that there's a lot of effort wasted for something that makes no difference to the end user. Why duplicate the whole thing just to make deployment (something that happens once) a bit easier?
It makes a difference to me what I put on my server. I don't run any rails apps at all because I don't understand the security implications enough and I haven't had a rails app I wanted enough.
You are right, I don't know that. But, I have an opinion on the likelihood of future vulnerabilities and my chance of being on top of them (and my ability to assess and remediate). My point was more that I care about the implementation language than saying that Go was better (for me, it's not).
I partially agree, but if you're going to be hosting your own server you should be considering the front end features, as well as making sure whoever is going to be maintaining the server it lives on won't want to pull their hair out.
I recently toyed around with InfluxDB which is a similar thing (written in go, no external dependencies) and it was pretty novel to have a 'self contained' binary like that.
I suspect it's especially helpful when dealing with docker images as well.
I definitely see the appeal of a single binary, and maintaining Stash has made us want to tear our hair out, but, in the end, the hours lost there are fewer than the hours we would have gained if the developer of this project decided to help another one. The new features would save us much more time than time spent administrating it.
Whenever I see things like "Why duplicate the effort, help with the existing ones", I cannot help but wonder how people fail to recognize that all great things had once a beginning. Gogs may or may not turn out to be great, but thinking that because it duplicates effort, it's a waste is very short sighted. Examples? How about countless Linux distributions? How about git itself?
You obviously didn't read the README section titled "Purpose". Here's a copy:
``Since we choose to use pure Go implementation of Git manipulation, Gogs certainly supports ALL platforms that Go supports, including Linux, Mac OS X, and Windows with ZERO dependency.
More importantly, Gogs only needs one binary to setup your own project hosting on the fly!``
But even if "all it aimed" was to be a duplicate in another language, that's just part of what will define it in the future. Linus didn't "aim" for his "just a hobby, won’t be big" project to take over the world and it did. Public open source projects have some of the most unpredictable paths - I'm not sure why you're trying to imply this one's an exception and it'll go nowhere!
Absolutely. I also think it's ridiculous that every language has it's own package manager, and some of them work in considerably different ways. Considering the amount of work put into NPM, Gems, PIP, Pear, Brew, RPM, APT, etc... this should just be a solved problem by now.
Oh god yes, we're in a state of package manager hell with all these languages, the worst part is that they all act so differently that it becomes hard to manage with puppet / chef etc...
Gogs was on the HN front page yesterday[0]. The one cool thing that Gogs has for it is being written entirely in Golang. It does all of its work with Git with it's own implementation of Git[1]. This allows it to work and build on all platforms that Go is supported on without having to worry much about 3rd party tools.
My previous experience with Gitlab (and others) led me to Gitblit: http://gitblit.org/
Gitblit is in another universe in terms of ease of installation, upgrade and maintenance, and very close on features. Even with a .deb package for Gitlab, my upgrade experience with previous versions wouldn't make me leave Gitblit. It's just dead simple.
Moreover, Gitblit uses plain text files for everything. It may not scale to thousands of users, but for small to medium size teams, it certainly makes maintenance, backups, and migration easier.
We've been using GitLab for our production projects for almost a year now.
The biggest reason for moving from GitHub to GitLab was not having to worry about additional cost for creating new projects (we have hundreds of projects and most of them are rarely accessed long after they were created).
It's also neat that we have the ability to customize GitLab if we wanted to, e.g. in 2012 we ran some experiments to create projects from templates directly in the GitLab interface [1]
And lastly, since we're not in an environment with six-digit numbers of users and constant DDOS attacks - we're able to keep a much better uptime than we had before with GitHub.
We have gitlab set up at work for our small team, but we never use it. We just do regular old git operations from the CLI and use e-mail and Bugzilla for issue tracking. I've wondered if maybe there was a feature of Gitlab we're not using that we should, but so far nothing's stuck.
We do merge requests by hand (there's several ways to do reviews/merges with git CLI), and communicate on bugs or e-mail threads. Oh, and I forgot to mention before we integrate git with Jenkins for CI and testing/reviewing/merging.
When we migrated over from CVS to git, we installed an instance of GitLab. It is really awesome, a private GitHub for your needs. The setup was a pain though, even after following the instructions. Nice to know they have a single installable package now at https://www.gitlab.com/downloads/.
We also use Atlassian Stash and JIRA for a client project (the client migrated from CVS to git) and honestly, found it to be quite similar in functionality and not too much better for the extra costs. Mostly, it helps that both (Stash and JIRA) are linked together, but I'm sure that can be done with GitLab and another issue tracking software like Bugzilla.
I just got my install of Gitlab working last night. I used the omnibus package (bundles its own nginx, ruby, postgresql, etc). I had to tweak the omnibus settings out of the box because unicorn was timing out on the initial page load.
After I fixed that, I disabled the bundled nginx so I could instead use the system's nginx. I had to modify the chef configuration scripts to change directory permissions so the www-data nginx could read the git-owned socket.
I'm very happy now that I got it working! My only nitpick (aside from some installation frustrations) is that the syntax highlighting for large files can be very slow. Does anyone have any tips for that?
If you like GitLab, checkout GitHost (https://githost.io) We provide hosted private GitLab instances. We handle upgrades, security fixes, and backups automatically.
One thing I’m curious about is performance, as with a personal project I found the `grit` git-ruby bindings rather sluggish when loading in multiple repos… The new `rugged` bindings are supposed to perform much better and if I understand in time Gitlab will switch to them.
An open source alternative for Mercurial and hg repositories is RhodeCode [1]. Source code at [2], this is RhodeCode running their own software. It's a nice solution for those who prefer Hg.
We're using GitLab for source code and issue management, as well as for internal documentation, and I must say it's really great piece of software. Plus, it's very actively developed and gets new features/fixes all the time.
We use GitLab where I work. I was finally able to set it up a few months ago and we've been using it quite heavily since.
Whilst we like using it, the UI doesn't always feel intuitive and has changed a lot over the last few versions, 6.8.0 feels worse to us — mainly due to the weird Merge Request UI changes. https://github.com/gitlabhq/gitlabhq/issues/6842
Still, I personally prefer the look and feel of GitHub. But it's a good free solution and we're really grateful for the work people put into it.
For solo work as a dev surrounded by hardware people, I set up GitLab. Installation took a lot of effort and had a surprising number of service dependencies. For a single user it wasn't worth my time to install or maintain. Though, it is a really nice product once running.
I switched to Gitweb and sd (http://syncwith.us/sd/using/). I don't love sd, but the overhead of managing source and tickets for myself makes the combo worth it.
Gitlab now has prepackaged downloads available for Ubuntu and CentOS[0]. I originally setup 2 Gitlab servers a long time ago, one I replaced with the new package version and the other I'm fixing to. It was tough to maintain and upgrade if it worked, but the package versions have been super simple.
Been using gitlab for solo dev at work and at home for everything that needs tracking, not only coding. Like you, attempted an install and gave up and used bitnami in the end. The only disadvantage is that the bitnami installers are a few point releases behind.
At my work, we aren't using gitlab, but looked into it for our own hosted git and it's pretty nice, considering you can do properly managed repos. We do currently use phabricator though for source-code review, which is pretty nice. You can also introduce new code into the system through it using their arc tool. I think a mixture between gitlab & phabricator is pretty nice. Using phabricator for new feature buildout & gitlab for bug tracking would be the ultimate setup for me.
We switched from github + Gitolite to gitlab a few months back and we're loving it. We've had no issues with it and it's really been a great move for us.
At my current job we didn't have any kind of version control for our source,(not even a sharepoint to dump things into).I spent some time trying out a whole bunch of different intalls and finally settled on Gitlab. It's pretty nice and I was able to get it up and running relatively quick once I put it in it's own instance rather than sharing a postgres install with something else.
My organization has been using Gitlab for a while now. We had a few issues earlier with integrating LDAP authentication and sorting out attachments for the wall, but the latest version does seem to fix most issues.
I am still not very happy with the wiki though (doesn't support folders, no way to upload images, doesn't look very good)
Our company has been using Gitlab since Dec 2012, we had a small team and small code base back then. While searching for a good inhouse github replacement I found GitLab had what I wanted and was worth the time effort. It has been nice to see the evolution and all the features available now.
It's cool, and this is a nearly useless comment, but the logo looks to much like an alien out of a Whitley Strieber "non-fiction" story. A little creepy I'm saying. Gitlab needs some branding design love.
I was thinking what GNU could be if they launched GitLab or some alternative to replace the archaic Savannah. It could take the project to a whole new level.
What about CI (builds)? There's a lot of options here, but Jenkins is pretty good. It's a bit of a hack, but I sometimes use it as a quick way to put a frontend on a shell script. The build history is an audit log and the job config history tracks changes to the script.
I'm obviously biased since I wrote it, but my Git and GitHub pull request browser is a pretty cool webapp. If you are a JavaScript hacker, I think you'll like its programmable metadata technology.
I wouldn't download the current beta version though. I'm currently testing a newer version with some enhancements which should be available for download by tomorrow.
Out emails are hosted on our company's server. Facebook and Twitter are publicity channels with public information only. And we don't even have that important corporate secrets.
You might trust US companies, but after Snowden many people don't trust the US anymore (industry espionage). And there is no reason if you aren't a one man shop to not host such things yourself.
I'm at a school. We've got hardware for VMs but zero budget. I was/am tasked with getting a basic Git server up-and-running, and GitLab hit the necessary points of (a) running on a Linux VM (b) having a GUI for Git and (c) being free.
I could see us using GitHub further down the road after we get some best practices in place and start using Git more, but for the time being GitLab is an excellent way to test the waters, especially since the GitHub Windows and Mac apps will work with an arbitrary 'origin' URL.
Long time ago we also assessed GitLab and found it usable but not quite there yet for production use. Though it looks nicer now.