GitLab keeps surprising me with the consistency and quality of their releases. They are really putting GitHub on the spot at the moment and I for one love the competition in this space
I've recently moved to pushing all my open source code to both GitLab and GitHub, but using GitLab for actual issue tracking, continuous integration, build tests, etc. I've found GitLab's integrated toolset to be superior to what GitHub currently offers, and in truth there isn't really anything I feel like I've been missing (some tools like Code Climate are only free for GitHub accounts, but it's easily resolved by just using both).
Plus the GitLab team has just been killing it with each release, and it just feels good to use open source (and be able to open issues, vote on improvements, track changes for the upcoming release...). Free private repos is just icing.
Setting up a project for both just takes a few initial commands to configure git:
Oh, good tip! Up until this moment I thought a remote mnemonic (e.g. "origin") could only refer to one. I didn't realize you could stack several behind a mnemonic.
Effectively. My project still gets pushed to GitHub and lives there, but I've disabled every feature I could (you can't disable PRs, but it's easy enough to redirect PRs over to GitLab).
Code Climate can still happily read from the GitHub project and I can add the badge to the README if desired, which is visible on both GitLab and GitHub.
And since origin pushes to both, they are rarely if ever out of sync.
And by using GitLab I get GitLab CI instead of Travis (which is quite nice), GitLab's amazing Issue tracker and board, which blows GitHub away, more fine grained control over merging (no more forced --no-ff merges if you don't want), Issue and MR templates, an activity stream, far more control over your project's settings... really I can't say enough good things about my experience with GitLab over the last ~6 months.
GitLab can actually keep your GitLab and GitHub repos in sync automatically! Check out the "Mirror Repository > Push to a remote repository" option in your project's settings.
Congrats on the release. Haven't tested this version, but have tried recent versions and if there's one thing that I think GitHub still runs circles around GitLab it's accessibility. If you don't believe me, try firing up a screen reader and see which you find easier to navigate with your eyes closed. In some cases you'll run smack into a brick wall with GitLab. So if there's one area where massive improvement is needed (and would be appreciated) it's accessibility. Happy to help on this front, but I know for a fact there's already several open issues relating to accessibility for GitLab.
Thanks. I agree will still have work to do in terms of accessibility to screen readers. Feel free to file an issue, existing issues are on https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&sta... And of course code improvements to fix things are also very welcome.
Hi Kolanos, I count 6 GitLab command line interfaces of a different type. They might not provide all the features, but perhaps it provides a solution for visually challenged users.
https://about.gitlab.com/applications/
This is one of the few points I have to criticize as well. GitLab's design is a bit too chaotic for me. It's missing visual dividers in a lot of places, especially in the issue tracker. Also GitHub feels better on horizontally smaller screens.
Also having that big header plus tabs just grabs most of the vertical space in the screen, very bad decision now that most of the screens have way more horizontal space.
Almost all of the navigation redesign was excellent. The information hierarchy was made much clearer.
The only thing that confuses me and my coworkers about the new design is the decision to hide the left navigation bar behind a hamburger menu by default. It's great that we can pin it open now, but why hide all of that useful navigation behind an ambiguous, easy to miss, unlabeled icon?
> but why hide all of that useful navigation behind an ambiguous, easy to miss, unlabeled icon?
Few reasons:
1. After redesign its possible to use application without sidebar for most of day-to-day tasks. I personally use sidebar 2-3 times per day while using GitLab whole day. Keeping it hidden by default allow me to focus on context and save screen space (really valuable on small laptop)
2. Both sidebar and project navigation visible at same time confused a lot of users. For example user clicked on sidebar "Issues" while they believed it will take them to project issues page.
The issue boards are a big deal, so congrats on getting that out!
I've said this before, but one huge thing you guys could do that would draw in a lot of companies to Gitlab EE is if you supported custom issue fields [1][2] with various field types. That feels like a pretty logical place to go from here, so I hope you guys are strongly considering it.
Since using Asana, one feature I want in every project management / issue management tool is the @mention [0]. Asana's @mention allows you to link other tasks or issues very conveniently. Just like HipChat's commands feature mentioned in your release notes, Asana's @mention feature is extremely convenient.
Great! Thank you for letting me know. Any chance of supporting something like that for the wiki pages too? So that we can refer to other pages or headers in those pages using @ or # mentions?
If you copy-paste the URL for a specific comment into a new comment it will show as `#123 (comment 234)` and link to that comment. There is no special reference syntax to link to a specific comment, because it's much more likely that you have the URL to a comment on hand, than just its ID :)
The "Gitlab doesn't handle big commits" bug is still a thing, and the two issues open for it are still open (and have been for months).
8.11 overhauled the diff backend, which works great! But the front-end still chokes up and freezes because the default appears to be 1000 files worth of diffs. This still pegs my CPU and hangs my browser when the page tries to render.
The second time loading the page is always fast (maybe something caches somewhere), but the first time is slow and chews the heck out of my poor PC. :(
Any chance we could get some sensible limits on the amount of information shown in a diff? Nobody is going to wade through 1000 files of diff in a web browser, so there's no reason to jam things up trying to render it.
Is it a matter of taste or Github's UI indeed looks more professional than Gitlab's one? I've tried to switch from GH to GL hosted for my personal projects multiple times and no luck. I like the fact that Gitlab is open-source and it has a lot of features but I still don't feel comfortable using it. Any opinions and preferences on GH's UI vs. GL's UI?
GitHub has a better container in their CSS. GitLab defaults to letting text lines be overly long and this just makes the whole thing feel uncomfortable even if you think you don't mind it. Otherwise, I think GitLab is largely alright UI.
I think GH gives off this impression because the UI looks like it has more stuff going on at the same time. It's probably an illusion caused by GH's design having more contrast between elements. GL is trying to look minimalistic like a clean sheet of paper. But that's kind of my issue with GL's interface: the contrast between elements is so low that it really looks like a blank sheet of white paper. But it's not paper, it's an active screen, so it feels very straining. Sometimes I feel like it's burning my eyes. I get used to it after a while, but it's an issue.
If we're talking only about the UI, I have to admit that GL's UI bothers me too. I wouldn't say that it's not professional, I feel like it's really really similar to GH in terms of links, buttons, etc, but made different (and less usable) on purpose to not be exactly like GH's.
In terms of product/features, GitLab is so much better than GH though.
I migrated to using GitLab.com from GitHub for all of my publicly-hosted repos and use a self-hosted instance for some other projects as well. I love that I don't have to compromise features or usability when opting for the free software alternative.
With both GitHub and gitlab, I wish there was more work in making it easy to create pull requests without having to click around on a website.
I'll often check out software, notice something small that I can easily fix, and spend 5 minutes fixing and testing it. But then I have to spend another 5 minutes going on GitHub, forking the repository to my profile, going back into my shell, changing the URL for origin, pushing the change, going back to GitHub, creating the pull request on the project, and then going back to my profile and deleting the fork that I have no interest in maintaining. This should be so much easier.
That being said, I run Gitlab under a small docker box and I couldn't be happier with it. It's so darn easy to setup. Grats to gitlab team.
These GitHub commands are provided by hub:
pull-request Open a pull request on GitHub
fork Make a fork of a remote repository on GitHub and add as remote
create Create this repository on GitHub and add GitHub as origin
browse Open a GitHub page in the default browser
compare Open a compare page on GitHub
release List or create releases (beta)
issue List or create issues (beta)
ci-status Show the CI status of a commit
Depending how small the fix is, you can edit a file in any project right from the GitLab interface, and a fork and merge request will be created automatically in the background! The only thing left to do is to remove the fork after the MR has been accepted.
This doesn't really help for anything except for content editing (e.g., markdown). Consider the above example: the original poster now has all these files they've changed on disk. The best case scenario now involves opening all those files up one by one and pasting them into the browser's textarea. (Can you change multiple files this way and wrap it up into a single atomic commit? Whatever the case, this actually results in a lot more pointy-clicky, not less.)
A patch is a unit of change. Historically, that's the type of unit that the open source world has operated with. The only reason we're having this conversation right now is because GitHub decided to build on top of pull requests instead of patches for lock-in reasons. GitLab has no such motivations, so it's silly to continue following them, especially since Git has had native support for patches from the beginning.
GitLab has an API, and a it's possible to create merge requests through it. I scripted 'turn a commit into merge request' as a Gradle command at the company where I work. So, it's doable.
Someone else in this thread also linked to command line tools, I haven't looked at them, but those might promising.
I hope this is the intention. I'd love to migrate off Jira. Presumably like others, it's the reporting and accounting features for management purposes that have kept us tied to it.
Congrats to the Gitlab team for pushing this out the door so quickly!
Back when we built one of ZenHub’s [1] first features — task boards inside GitHub — we believed strongly that development teams needed a single source of truth in order to move faster and communicate better. That belief has underscored everything we’ve built since. It’s awesome to see further validation for this philosophy here with Gitlab!
Both of those formats also work in comments outside of slash commands, are automatically linked to the respective entity, and label references are rendered as pretty labels, with their color and description tooltip.
Using those characters also enables autocomplete in the Markdown textarea.
In the web interface, they are very convenient, but they are not required, so when using slash commands with reply-by-email, you can leave them out and write exactly what you have under "Instead of"
A tiny question: does this mean a workflow in which only one user would be able to merge a specific branch (say: master) is only available in the enterprise edition? I imagine this is quite a common workflow, even at smaller companies or non-profits. This essentially forces you to use an entire repo per user to do code review, even though oftentimes you wouldn't need this when you can restrict branch access to a specific (set of) users.
For example, I'm active at a small non-profit computer shop at the campus of my university, and we develop our own stock managementsystem inhouse. This would be a very interesting feature even for non-enterprise users like us, because that'd allow for easy code reviews without having to fork the repo.
CE does support restricting branches to specific roles: Master and Developer. In your case, I would suggest giving this single maintainer the Master role (which they already have if they're the owner of the project), making everyone else a Developer and configuring the master branch to only allow pushes (and merges) from Masters.
GitLab looks very tempting, congrats to their team.
Question: I would like to migrate from Github to Gitlab, but can not really move. Is there some bridge, which would mirror Github repos (with Issue tracker and pull requests) on Gitlab?
While you _can_ import data such as issues we do not have any automatic mirroring system for this in place. We do however have repository mirroring, but this _only_ mirrors the repository data.
You might be pleasantly surprised with the migration process of issues -- I had some inlined images and checklists in Github that got seamlessly migrated to Gitlab. I was pretty happy with how well it worked.
This is just in terms of ripping off the band-aid. I'm not sure of any mirroring, but I don't think that would be worth the hassle.
I have yet to understand where this kanban board stuff makes sense. Apparently, the Agile philosophy [0] introduced this to the software development world. Most implementations (Gitlab, Wekan) seem to miss central features (limits, cycle time stats).
I guess those boards serve as a issue tracker extension for short term development? How does that improve the process? Why do you need that on top of an issue tracker? Replacing the issue tracker is probably not idea?
I work at a small IT company that does website development for small businesses around the city. Our projects usually last around 1 to 4 months. We use JetBrains YouTrack with all open projects showing on one big board.
Each week we meet with project owners (somebody at the client company). They give us a list of tasks they want completed this week and we go over tasks we finished last week.
After the project is done, we move to only working on one-off issues they send. Usually bugs or small new feature requests. A simple issue tracker would work fine here, but we still have weekly meeting with our boss to show that we actually did work last week.
We already use self-hosted GitLab for our code, so I want to try out this new board feature to see if it meets our needs.
The visualization and instant-modification of kanban boards is really appealing from a task/issue management perspective. It shouldn't replace issue tracking, it can serve as a frontend to portions of it.
It complements the existing issue tracker, the issues and the labels are the same. You can use issues without the board but it might be useful to give a visual overview. In meetings it is frequently easier to use a board see the many issue at a glance and to drag and drop them.
I'm not sure we want to have the software enforce limits, but I do agree that you don't want any list/column to become too long.
I think it would useful if the admin could opt-in to have limits enforced. That is a central tenet of kanban methodology. While the default could be no limit, I don't see why self-limiting should be prevented. I can open an issue if you like. :)
The Gitlab version isn't a kanban board specifically, though they say it can be visually like one (its a more general thing and, as you note, it doesn't have the specific additional features that would make it usable as an automated kanban system, so you'd have to manually enforce process controls and collect data to really get what you'd want out of a kanban board.) I'd think of it more as a customizable dashboard view over the issue list (it doesn't replace the issue list, since its strictly drawn from it.)
Merge conflict resolution seems like something incredibly obvious to have, that yet is a pretty unique feature for the web UI. I've done a lot of stuff with GitHub's web UI, and I pretty much hit a wall any time I do something that's going to create a merge conflict, since I never really bothered to learn Git CLI. I saw GitBook did something similar to this a while ago, but that's for books, not code.
What made you pick Gitlab over Bitbucket? Both can be self-hosted, but I'm not sure yet which one to choose myself. We do use Jira/Confluence internally so we might want to stick within that ecosystem but I hear very good things about Gitlab. I believe both integrate well with Jira as well and support smartcommits. What were the advantages for you?
Great to hear you're already using JIRA and Confluence. Adding Bitbucket to the mix will give you access to a bunch of great integration features.
We've been working on making it easier for the entire development team to collaborate and give them the right information at the right time. Here is a selection of features that I think you will find useful:
I've been using GitLab for almost a year and I love it. I tried BitBucket and found it confusing and counterintuitive—the UI is crowded, as is the UI for JIRA and Confluence. (Don't forget that GitLab replaces Bitbucket and JIRA and Confluence, and actually does even more than that.) https://about.gitlab.com/comparison/#gitlab-ceee-vs-bitbucke...
Gitlab has a really great set of features and I appreciate the open and professional development style very much. It's very resource-hungry, though. At one point I just gave up and switched to Gogs. Less features, sure, but very fast, even with many users.
Yeah, if you want to use less resources Gogs is a great option. Did you know out team member Kim works on Gogs fulltime? https://about.gitlab.com/gogs/
Fascinating. I'd understand why GitLab and Gogs might not be competing with each other, but why invest in Gogs? How does that benefit GitLabs the company?
Joking aside. Most likely to get a foot in the door on competition and on git related features written in Go, which might supplement or replace parts of the infrastructure within Gitlab. They already use Go for the CI runner part and as a smart, Gitlab aware proxy.
We want to prevent a not invented here mindset. And we'll work on import export functionality. By the way, GitLab already uses GitLab Workhorse written in Go to do much of the heavy lifting. I would say it is more then a proxy. This project is unrelated to Gogs.
My job would never cotton to putting stuff on Github, so GitLab existing and being of such high quality has been fantastic. Really been impressed with it.
I'm seeing this as Gitlab working towards their Jira killer. With Mattermost also in the omnibus edition this is rather ace. Congratulations to the team!
congrats for the new release, here my critic (don't take me wrong, I use and love gitlab for so long, and the other features of 8.11 are really awesome)
* merge conflict resolution: It definitely looks cool and make conflict resolution BY MERGING easier than any other way i know BUT most of the time I want my co-worker to resolve conflict BY REBASING (i.e as if they had branched just right now) , following the principle that you merge from specific to generic. So though I definitely agree most of people don't care, but for larger team/project where you often need to make archeology and dig inside the commit history , the "master merged into feature branch" makes the commits tree look weird
Outside of this, it's maybe only me, but most of the team I've worker with where using a scrum-like taskboard (like http://taiga.io ) instead of a kanban-like, is it planned to be added/provide the option or (which I perfectly understand) do you plan on focusing on kanban and letting third-party project for those who prefer scrum ?
As for the Kanban board, as far as I can read in https://www.cprime.com/2015/02/3-differences-between-scrum-a... the only difference with a scrum board is that you can set a maximum number per list. Feel free to create a feature proposal for that, I've already heard that request before today.
hmm yes you're right, I was mislead by the name of each list on the blog post, it's true that nothing prevent me from naming each column "new" , "in progress" , "ready for qa", and "done" , my bad.
this + burn down charts (like proposed in https://gitlab.com/gitlab-org/gitlab-ee/issues/91 ) would really start for us to make gitlab embrassing the full life-cycle of our products.
As for resolving conflict by merging, thanks I didn't know EEhad this feature.
Shouldn't the video start with "We make software by turning issues into ideas", not the other way around?
We're always trying to promote this idea of "don't sell the product, sell the problem you're solving" and your opening statement completely tips that on its head.
Not knocking GitLab in any way, I love your product and have used it for a while. Amazing work. Just me being a pedant ;)
> Shouldn't the video start with "We make software by turning issues into ideas", not the other way around?
They're using "issue" as in "issue tracking", not "issue with how the world works". In this sense, you take an idea and write it down as an issue, which can then be discussed and implemented.
I'm glad there's starting to be a good amount of choice in this realm of tools!
I've actually just lately been looking into a new all-in-one package like this for our company. Git hosting, code reviews, issue tracking, wiki, and nice project management features all in one place. My current systems-under-test are Phabricator and Jira.
Anyone have an opinion on how GitLab compares to those two?
We compare GitLab with a bunch of other tools on our website: https://about.gitlab.com/comparison/. We don't have a section on Phabricator yet, but if you end up trying both GitLab and Phrabicator, please consider writing down some of your observations!
I'll see if I have time to evaluate yet more tools very thoroughly , but if I look into GitLab I'll definitely hit you with something for that page :)
one thing that jumps at me from those comparisons is that mostly all of them are against other tools that are mainly for repository hosting. Is it intentional, and similarly the main idea of GitLab itself?
We are mostly compared to those tools, that is why we added those sections. I think it might get unwieldy if we added non repository hosting tools too.
This is awesome. Is it possible to have a central set of issues per group? Many (real-world) projects have issues that span across multiple (GitLab) projects. I guess one could create an "empty" project for issues, but this is hacky. Thanks again.
Great suggestion. With milestones you can already aggregate issues on a group level, but it makes sense to have a group level issue board too. I created an issue in https://gitlab.com/gitlab-org/gitlab-ee/issues/911
My first impression of the Issue Boards is that it reminds me of Trello quite a bit! I happen to like Trello, and whether or not this new feature was Trello-inspired I'm excited to give it a test run.
We were definitely inspired by awesome software such as Trello and Asana. We've woven it into GitLab and have some iterations to go before it's exactly what we want, but we believe we've shipped something useful so far.
Would love to hear your feedback and suggestions for improvements.
Mattermost is not enabled on GitLab.com, in part because it's not prepared for multi-tenancy, and in part because it is shipped with the GitLab package specifically for people who want to have a self-hosted development and collaboration environment. If you're fine with using hosted tools, there are plenty of great hosted chat tools out there!
DouweM, it is possible though to do this. Although a good seamless integration would require some extra work from our end. I've proposed this in an issue[1]. It is not planned though, at this time.
For my 2¢, it would be really great to see some "official" love for Haskell at GitLab :) E.g. having Haskell tools installed on shared runners would be pretty nice!
I'm also curious to know the state of functional programming at GitLab. I know you guys mostly do Ruby, but would you be open to employees using functional languages or frameworks for work? (e.g. Elm, Elixir, Haskell and other exciting functional stuff)
