Disclosure: I'm the CEO of GitLab and we compete with GitHub.
We think of ourselves as an open source company. But today paxcoder on Hacker News rightly remarked that calling it an open core company is more accurate.
We ship GitLab CE which is open source and GitLab EE that is closed source. We try to be a good steward of the open source project. GitLab EE is proprietary, closed source code but we try to work in a way similar to GitLab CE: the issue tracker is publicly viewable and the EE license allows modifications.
When we mention that GitLab is available in an open source edition people frequently ask "Isn't GitHub open source?". I understand the confusion between open source hosting and open source software. The hosted service GitHub.com is free for open source projects and it has fundamentally improved open source collaboration. But the software GitHub's service is based on is closed source.
Please note that while we think of ourselves as an open source company it would be more accurate to call it an open core company since we ship both the open source GitLab Community Edition and the close source GitLab Enterprise Edition. Thanks to paxcoder for pointing this out on Hacker News.
[GitLab] began as a labor of love from [Dmitriy Zaporozhets] and [Valery Sizov], who built the first version together in 2011. Like many open source authors, they were only able to work on the project part time. [Sid Sijbrandij] joined forces a year later and created [GitLab.com], the first SaaS offering and first experiment with monetization.
This post is part of a series Celebrating 1,000 Contributors
There are clear benefits to contributing to open-source projects. For starters, you'll solve your own problems more quickly and you will have a positive effect on your favorite projects.
However, the barrier to entry can be high for first-time contributors. Perhaps you feel your coding skills are not up to par, or maybe you aren't a programmer at all. When you do approach a project, you may find the contribution guidelines are unclear, the maintainers are unresponsive, or you may disagree over priorities.
I'll give you some practical advice on overcoming these hurdles. We'll also look at the ways GitLab tries to make contributing easier in our own project.
Since GitLab Enterprise Edition 8.2 you could sync all changes from a remote repository to one on GitLab.
In GitLab 8.7 we introduced the second part of the mirroring functionality: the ability to push changes to an external repository from GitLab...
In 8.6 we added a feature allowing you to move issues between projects.
If you work on multiple projects, it's possible to accidentally create an issue in the wrong issue tracker. It's a seemingly simple mistake that is easy to miss. Let's say you don't catch it right away and you do a decent amount of work on the wrong project. Now, your "seemingly simple" mistake just became a bigger one. We've all been in this position before. With our 8.6 release, we want to avoid the panic that can come from creating an issue in the wrong project. Now, if you create an issue in the wrong project, you can easily move it to the right one.
In active projects, it can be hard to keep track of issues that are important to you. For example, a project like GitLab has thousands of issues, but you might only be interested in those related to performance.
You can already mention people in GitLab by using someone's @-handle, but as more people join a project, it becomes harder to keep track of who is interested in what.
To solve this, in GitLab 8.6 and up, you can subscribe to a label. Whenever an issue is tagged with the label you subscribed to, you will get a notification. This is irrespective of your notification level to the project.
At GitLab, we’re really proud to support the open source projects which underpin our service. Obviously, Git is a main part of absolutely everything we do. We recently sponsored Git Merge, an event organized by GitHub and sponsored by Atlassian, Bloomberg, Compose, SAP, and of course, GitLab. Even competitive organizations must work together to improve upon and negotiate the direction of key open source software. On the day before Git Merge, we joined the Git Merge Core Contributors Summit to discuss the direction of the project and new developments.
Sytse, Job and Marin attended to represent GitLab and learn more about what is happening in the core Git community. Here are our notes and impressions from this event.
Since GitLab 8.6, in both Community and Enterprise edition, there is a small checkbox available when you create or edit an issue, allowing you to mark an issue as confidential.
In some ways it’s a simple feature, but there are complex considerations. The main point is to keep the confidential issues secure. However, taking care of those considerations caused some problems during development which are typical when you develop a feature for a relatively long time (in this case two weeks). We'll look at that in this feature highlight.
As a Service Engineer I'm in constant contact with customers, listening to their needs, and I've noticed a steadily-increasing interest in SAML from our Enterprise Customers. That inspired me to dive a little deeper into the topic in an effort to improve our integration with SAML and to add better documentation. I hope this helps our customers and our community to better understand this feature.
In this blog post I'll give you an overview of what I've been working on, how it affects GitLab, and what we plan to do with SAML in the future. Our plan is to bring SAML up to par with the features that LDAP offers within GitLab.
In our latest webcast, we looked at highlights from GitLab 8.6.
Our special guest, Douwe Maan, gave us a live demo of the latest features in GitLab 8.6 with a special focus around improved confidentiality. We looked at project configuration and user permissions to start. Douwe followed a typical GitLab workflow to demonstrate new features which make it easier to keep track of what is happening (subscribe to label) and features which save you time (create a new branch from an issue), and more.
If you're new to GitLab, this webcast will give you a good overview of using GitLab, and if you're experienced you get to see the new features in action.
Sign up to our newsletter to make sure you don't miss any of our live webcasts.
I've recently joined GitLab as a Developer Advocate. Part of my role will be traveling to community events where I hope we'll meet in person. I'm also an experienced Ruby developer. As a rubyist, naturally, I've heard about GitLab and even used it couple of times.
The first two weeks working with GitLab have been full of pleasant surprises and dispelled delusions. If you haven't been following GitLab for the last two years, this post is for you.
If you’re interested in an indication of productivity of individual software engineers (programmers), don’t look at commits or other measures of activity. Look at consistent progress instead. In this post we'll consider some ways people evaluate or represent productivity, and I ask for your thoughts on what you track and what you think matters.
We held our first webcast last week, and we’re so delighted you came along. We looked at new features and improvements included in GitLab 8.4. It was excellent to see so many questions from the audience. It gave us ideas for future webcasts too, so keep the feedback coming!
Sign up to our newsletter to find out about the next one.
Please read the up-to-date version of this article!
Developers rely on multiple platforms to manage repositories, depending on client and project needs. They might contribute to a community project on GitHub, while working on one client's on premises GitLab instance and another client's project in Mercurial on Bitbucket. Confusion can arise when you switch between platforms. In this post, we have a handy reference guide to explain some potentially confusing terms, especially if you're new to GitLab.
Some GitLab users who should be celebrating the festive season might be suffering from post-Christmas blues. Maybe you didn’t get everything you wanted for Christmas. We feel partly responsible for that, and we want to make it up to you.
We’re so happy when people contact us to ask for some swag: a sticker, a t-shirt, anything! Then we feel sad because we don’t have a swag shop and we have no way to get people something to show their appreciation. This is a great problem to have: too much love.
So now we’re hard at work to get a swag shop set up. If you want to be the absolute first to know about it, sign up below. Bonus: You’ll be entered into a prize draw for a gift. Good luck!
There's another way to win too.
Since October 2011 we’ve released GitLab each month, without fail, without exceptions. On December 22nd that will be 49 monthly releases, not including patch releases or security releases. In this article I’ll give you an overview of how we release our product and how it helps our team improve process and documentation.
Your release strategy affects how you plan, develop, test, and publish your software. At GitLab we follow a monthly release cycle which works really well for our project. If you’re running an open source distributed software project, you might consider if a predictable time-based release can help your project. You can even get started by using our release cycle documentation as your template.
In GitLab 8.0 we worked hard to refine the UI so it is really enjoyable to use. After the release we received a lot of positive feedback. However, users requested a few customizations to help the UI better fit their daily use. We considered all of this feedback and are happy to share some new user preferences in GitLab 8.1.
Among these new user preferences are the ability to choose between a fluid or fixed width layout and the option to choose activity as the default dashboard instead of the project list.
Code review is very important. You don't want to run the risk of technical debt. Actually doing code review is another matter. Besides the variety of tools and tricks for the act of code review, the timing is vital.
Quora published a great article about maintaining velocity in projects. The article is really great but we think that their post production code review is timed wrong.
Have you ever wondered how GitLab employees use GitLab? Before I worked here, I always wondered how some products are used for their own creation. This actually has a name and it's called dogfooding.
Some months ago I went to an event in Facebook Headquarters and it called my attention that they use Facebook for everything, including registering guests and getting feedback. Most companies have certain technical departments that will work on making everything more “user friendly” or less technical for the rest of the company. In GitLab, we all try to learn how to use our platform and do everything that’s technical ourselves. That allows us to test our product and have more confidence in it.
When I started in the software industry 10 years ago the idea of putting your company's crown jewels (source code) on someone else's infrastructure was preposterous. It was typically the domain of open-source projects or hobby programmers looking to avoid server management, taking backups, etc. Although some services have been around since the late 90's it wasn't until the second half of the last decade that 3rd party code hosting became more acceptable, especially among SME's. There's been a proliferation of providers in the space since.
The advantages of SaaS over on-premises deployments has been written about ad nauseam and there's certainly good reasons why but let's take a moment to highlight some of the reasons why on-premises is not such a bad idea after all.
Say your department has five teams, and each team is running its own code collaboration tool. One of the teams is still using SVN. Other teams have moved on to a Distributed Version Control Solution (DVCS), but the teams all use different solutions.
All the developers are happy at this time. They get to use their own workflow, the one they prefer. The team leads get to manage tools that they are already comfortable with. You don't have to deal with people complaining that their tool sucks.
But underneath all that happiness, trouble slowly brews.
Working on an open source project, we're so lucky to receive many merge -and pull requests. Not unlike dating, we see a number of different git personalities. Do you recognize yourself or one of your colleagues in one of them? Let us know in the comments or tweet about it with #gitlab.
We get asked a lot how GitLab compares to GitHub Enterprise Edition, the version of GitHub that you can run on your own servers. In this post we'll briefly discuss what we see as the advantages of running GitLab Enterprise Edition, our paid version of GitLab. The three main advantages are that GitLab focuses on enterprise needs, is easier to operate and scale and it is more inclusive.
This blog post will give a short overview on how GitLab bugs are handled, and what you can do after you identify a potential bug in GitLab.
The GitLab community differentiates between three different types of bugs:
Git is very easy to use and abuse.
A single git push --force command can easily ruin the day for a lot of people:
As a result, these [186 Jenkins'] repositories have their branch heads rewinded to point to older commits, and in effect the newer commits were misplaced after the bad git-push.
On November 10, 2013, a Jenkins developer had accidentally forced pushed to 186 repositories, bringing them back two months in time.
The power that Git gives you to change history is great when you're working alone,
but potentially disrupting if you're working with others, as shown by a poor Jenkins developer.
When you're working with others, not only do you not want to allow git push --force,
but before anything is committed to the main repository or branch, the code should be reviewed.
At GitLab we believe that by preventing force pushes and by stimulating code review practices, mistakes can be easily avoided and code quality will improve. To make it easier to work together with code and Git we have created a surprisingly simple permission system, built on top of an elegant authorization method.
The most up to date version of the content of this blog post can be found in our documentation.
Version management with git makes branching and merging much easier than older versioning systems such as SVN. This allows a wide variety of branching strategies and workflows. Almost all of these are an improvement over the methods used before git. But many organizations end up with a workflow that is not clearly defined, overly complex or not integrated with issue tracking systems. Therefore we propose the GitLab flow as clearly defined set of best practices. It combines feature driven development and feature branches with issue tracking.
Organizations coming to git from other version control systems frequently find it hard to develop an effective workflow. This article describes the GitLab flow that integrates the git workflow with an issue tracking system. It offers a simple, transparent and effective way to work with git.
Sometimes you need additional control over pushes to your repository. GitLab already offers protected branches. But there are cases when you need some specific rules like preventing git tag removal or enforcing a special format for commit messages. GitLab Enterprise Edition offers a user-friendly interface for such cases.
For each project you can have unique Git Hooks. You can set them by going to Project settings -> Git Hooks.
GitLab is a massive open source project with over 600 contributors, all working together to create an amazing platform to collaborate on code. Every month on the 22nd, a new version of GitLab is released, and every month new features are added. To make you aware of the power of GitLab, we walk through some of its features in these blog posts.
We start by looking at GitLab Groups. GitLab groups allow you to group projects into directories and give users access to several projects at once.
GitLab has a very powerful issue tracker that integrates completely with the GitLab workflow, allowing you to reference and even close issues with commits. On top of that, you can easily comment on someone's code line by line, integrate GitLab CI,...
360i, the increasingly successful digital media company from the US, agreed to spend some time with us and explain how they're transitioning to GitLab. You can read the case study here.
While moving away from SVN, they chose GitLab because it was...
The awesome git podcast GitMinutes did a GitLab episode where the host Thomas Ferris Nicolaisen interviews our co-founder Sytse Sijbrandij. The history of GitLab, GitLab Shell, Gitlab CI and git tricks are discussed.
