Awesome! You're about to become a GitLab developer! Make sure you've checked out our handbook beforehand, so you get a feeling of how we work at GitLab. Below you'll find everything you need to start developing. If something is missing, add it (as goes with everything at GitLab)!
We have two main GitLab instances, as explained in the general onboarding.
To start development, follow the instructions for the GitLab Development Kit.
Almost all repositories are available on both gitlab.com and dev.gitlab.org. We also mirror our biggest projects to GitHub, making them more widely available for people to contribute.
This is the community edition of GitLab. Most of the development happens here, then gets merged into GitLab EE periodically. Unless you're making a change specific to GitLab EE, add it to CE.
This is not an open source project, but we made the source code available for viewing and contributions. As of version 7.11, it requires a license key to be used. To be able to run your own instances for development you can use one of the shared licenses (like https://license.gitlab.com/licenses/1449) or you can clone https://dev.gitlab.org/gitlab/license-app and generate your own licenses.
GitLab Shell handles Git commands for GitLab. It's an essential part of GitLab.
Gitlab-workhorse is a smart reverse proxy for GitLab. It handles "large" HTTP requests such as file downloads, file uploads, Git push/pull and Git archive downloads.
Omnibus GitLab creates the packages for GitLab.
GitLab.com runs on Microsoft Azure. Many people in GitLab also have instances on DigitalOcean. If you need a VPS for any reason, it's probably easiest to set one up at DigitalOcean. Ask another developer for access.
For everything related to infrastructure, check out the Infrastructure handbook.
Please see the engineering workflow document in the handbook.
One of GitLab's strengths is its high quality of software. To achieve this we've introduced some requirements to all source code that is contributed. All requirements are mentioned in the Contribution guide. Make sure you read and follow it.
GitLab can be installed through an Omnibus package or from source on different Linux distributions and macOS. In order to maintain portability, we need to avoid adding extra dependencies and use of exotic database extensions. Every time you choose between changes in the application code or adding new dependencies, you should give priority to the first because this is easier to maintain and setup. If you still need to bring new dependencies to GitLab, ask another developer or the CTO for advice.
In GitLab all code should go through a review process before it can be merged. Make sure you submit a merge request for any changes you've made. When the merge request is ready, it should be assigned to someone else on the team. This person is then responsible for reviewing your code and merging it. Optionally, you can request another developer to help or review by writing a comment. If a merge request is not assigned, it will probably be ignored and create unnecessary delays.
Don't work on one task for multiple days before submitting a merge request. Even the biggest task can be split into smaller tasks. Try to submit a merge request for each part of the functionality. This means that we expect multiple merge requests per week from you. Smaller merge requests are more likely to receive good feedback and will get merged sooner.
Unless the change is very minor, or is fixing a bug that was introduced in the same version, add an entry to
CHANGELOG-EE when applicable). Do not include your name in the entry as we only do that to give recognition to volunteer contributors.
When building and publishing Gems for GitLab make sure multiple developers have access to said Gem on RubyGems.org. This ensures a Gem doesn't end up being orphaned because the original author left, lost their credentials, passed away, etc. When publishing a Gem you can add some or all of the following people as co-owners:
You're of course free to add other developers as well.