The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Last updated: 2022-12-07
| Section | Stage | Maturity |
|---|---|---|
| Dev | Create | Loveable |
The Source Code Management direction page belongs to the Source Code group of the Create stage, and is maintained by Torsten Linz, who can be reached at tlinz@gitlab.com.
This direction is a work in progress, and everyone can contribute. Sharing your feedback directly is the best way to contribute to our strategy and vision. Please, comment and contribute in the linked issues and epics or raise an issue yourself in gitlab-org/gitlab if you don't find existing feedback that matches your thoughts.
Source code management (SCM) is the foundation of an organization's software development practice.
Building great software depends on teams working well together. Teams can rarely be divided into areas of complete independence. As cross-functional security, compliance, and growth teams are formed, or new services and libraries are created, effective coordination and collaboration are essential.
To achieve this, teams need to protect production while making it easy for everyone to contribute. Source Code Management provides the controls to define the rules and workflows for this purpose:
GitLab Snippets allows users to share small bits of code and text by directly linking, downloading, or embedding them in web apps within an HTML tag. Each snippet is essentially a lightweight Git repository, meaning they are versioned and even support multiple files.
Commonly Snippets are often used for smaller pieces of code that are reused among several projects, additional documentation for specific one-off scripts/functions and instructions for using the main project.
While the principles have been around for half a century, SCM is not without challenges. SCM needs to address a large set of requirements that are partly contradicting:
Git is the leading Version Control System (VCS) and is loved by developers. It excels at tracking changes in source code and makes it easy and transparent to merge changes from different developers into one code base. GitLab's source code management builds on top of Git adding functionality that aims to address the above requirements. For example, access control to code repositories or requiring code reviews before merging changes. Source code management and the create stage represent the most popular features in GitLab.
Yet, despite their appeal, neither Git nor GitLab SCM are perfect. Here are the current main shortcomings:
Therefore, the vision for Source Code Management at GitLab consists of three pillars:
Note: SCM is not only the most used function in GitLab but also the one with the longest history as it has been there from the beginning. As a result, we get a lot of feedback and have a long backlog of issues. Therefore, we need to spend a considerable share of our teams’ capacity on issues that are not at the center of this vision but address bugs, stability, security, and scalability to keep our users and customers happy.
Source code management mainly targets software engineers but also anyone who is contributing to any type of project. To that end, we target all the user personas we describe in our handbook, with a special focus on the following:
Sasha (Software Developer): targets full-time contributors to all types of projects (commercial, OSS, data science, etc.). These users expect and need a high level of reliability and speed in their interactions with both project files and Git.
Delaney (Development Team Lead): targets users who oftentimes have elevated roles that allow for the management of project settings, such as access control, security, commit strategies, and mirroring.
Devon (DevOps Engineer): targets engineers tasked with supporting and enabling software teams. Their tasks often revolve around platform creation and maintenance, where GitOps] workflows are crucial.
The Source Code Management category is expansive and encompasses a broad set of features. Which features are leveraged, how they are leveraged, and to what extent depends on the size of the development team and the complexity of the product that they are building. We find that as the team size grows, so does the complexity of the software product. For these reasons, it is challenging to define a single-user journey that captures how our users move through Source Code. That being said, there are five main buckets we can use to group the jobs to be done by our users. Understanding this general workflow helps to focus product development and discovery when exploring how to streamline the Source Code experience
We intend to define and document the user journeys our specific personas take and how those differ based on the size of the development and the industry in which they work.
These topics represent our longer-term plans for the next 12 to 18 months. As these are all initiatives that still require problem validation and solution refinement they are more likely to change than our shorter-term plan outlined below under What's next and why.
Report number of lines per language in repository charts
Currently, in repository analytics, we report the used programming languages only as relative percentages and base these percentages on the file sizes in bytes. As the size of files depends largely on the programming style, this is not very helpful. Also, it is not comparable to nor aggregatable with other work that is usually reported in lines of code. We have received tons of great feedback in the comments of this issue and our analysis of these now focuses on understanding which personas have which specific needs to address the problem(s) in the right way.
Improvements to Code owners
Large organizations with many projects and large projects need to enforce review policies so that they can ensure the correct teams and individuals review changes that impact them. File owners will be automatically added to related Merge Requests (separate feature), but it is also necessary to add controls to prevent changes directly to important branches without approval.
We should continue to improve on the first iteration of code owners. WIP opportunity canvas can be found here - only accessible to internal GitLab team members.
There are different ways for development teams to set up merge strategies depending on their software development, code review, and compliance practices. While we encourage customers to practice GitLab Flow, we also need to support different strategies as there is no one right way for our customers. This effort streamlines the settings that allow users to create different flows and adds the option.
Large repositories are difficult to manage in Git because they are difficult to scale, have performance concerns, require large amounts of storage, and suffer from loss of per-service semantic versioning. We see large repositories in situations where a company has a lot of large files, such as binary assets or they are operating a monolithic repository, more commonly known as monorepo. A monorepos is a software development approach where code for many projects is stored in a single repository. Monorepos provide several advantages such as reduced complexity, code reuse, easier collaboration amongst teams, and streamlined dependency management. However, they have several drawbacks as aforementioned. We have the opportunity to improve workflows for large repos via improvements to partial clone and sparse checkout. WIP opportunity canvas can be found here - only accessible to internal GitLab team members.
In 2021, we focused on the availability, stability, and security of our SaaS offering. This was a tremendous effort. Since Q2 2022, we have been able to reduce our efforts in this domain steadily and now spend almost none of our capacity on such work as our SaaS offering is in very good shape now. This allowed us to pick up feature work and fix functional bugs. The following is a list of some of the bigger and smaller features we have delivered since then.
FIPS 140-2 Compliant - FIPS compliance is a requirement for the US Govt to utilize a piece of software. It is required for any FISMA or FedRAMP system and cannot be waived. For GitLab to be directly usable within the US Govt, we need to be compliant. To contribute to GitLab's goal to meet these demands, the Source Code group contributed their share of work.
GitLab is working on making GitLab.com FedRamp compliant and the source code team has contributed their share of work (internal link).
Ability to enforce IP address restrictions for Git over SSH - Limiting access to requests from a trusted set of IP addresses may improve security. Until now, only the API and UI supported such access restrictions; SSH access was blocked entirely. SSH now also adheres to this restriction, and grants access only to requests coming from IP addresses in your list.
Block Git access protocols at group level - To improve security, you can now block Git access protocols that you don’t use at the group level. This is similar to the GitLab administrator setting but can now be set per group. By default, both HTTP(S) and SSH are enabled. In your group’s Settings > General > Permissions, scroll to Enable git access protocols and remove any protocols you don’t use.
Gitlab API for Protected tags: use group_id or user_id to protect tags - Enhancement to the Gitlab API for Protected tags to support setting protected tags using group_id or user_id like it is possible for protected environments API and protected branches API.
Improved and faster file browsing and syntax highlighting - We made multiple changes to improve the experience of browsing a repository and viewing source files. Rather than reloading the full page when moving from folder to folder, we now display repository files and folders with a single VUE application. Our repository tree view is more performant and stable now and working with files is faster. We have also switched from server-side transformations for files to client-side syntax highlighting. The rendering time for large files is now up to 66% faster.
Enforce Developer Certificate of Origin on all contributions. The Developer Certificate of Origin (DCO) is a per-commit sign-off made by a contributor stating that they have the right to submit the code to the project. By signing off on a commit, the contributor agrees to the terms published at developercertificate.org.
Now, you can easily enforce this Developer Certificate via a per-project setting to prevent contributors from contributing code that violates your license. When enabled, all new commits must include such a certificate of origin in the form of a line in the commit message Signed-off-by:.
Configure default names for branches created from issues. Define a custom template for naming branches created from issues. The previous setting {issue ID}-{issue-title-hyphenated} remains the default. To define a custom template for your project, go to Repository Settings > Branch defaults.
Ability to update access levels from Protected Branch API. So far, it was only possible to update access levels of protected branches via the UI. To do this via the API you had to first unprotect the branch and then protect it again with the new setting. With this improvement that we are working on currently, you will be able to programmatically change which users or groups are allowed_to_push, allowed_to_merge, and allowed_to_unprotect and change more settings. This way it is much less likely that bots that change such settings accidentally leave branches unprotected.
MVC: view source code rules organized by branches - We are bringing the settings for protected branches and merge request approvals conveniently in one single place under Settings > Repository > Branch rules. Moreover, as the name suggests, they will be viewed through the lens of a branch as they naturally relate to such. While no functionality will be changed this significantly improves discoverability and intelligibility of your settings. Previously, these settings were in far apart places making them hard to understand as we learned from user feedback including a recent SUS study. This is the first iteration of this work and will allow viewing only. To change the settings you will need to use the existing settings as you know them. Next, we intend to allow the editing of rules in this single place that organizes the rules by branches.
Sign commits with your SSH key. Signing commits just got a lot simpler. Use SSH keys to sign commits, and provide others with confidence that a Verified commit was authored by you.
Until now, it is only possible to sign commits with GPG keys or with X.509 certificates, requiring you to manage different key types for authentication and for signing. If you have ever interacted with GitLab from the command line, you most likely already have an SSH key set up in GitLab for the purpose of authentication. You will be able to use the same key also for signing commits. All you will need to do is add three lines to your local git configuration and all future commits of yours will be signed.
Show how far behind/ahead a fork is from the upstream project. On the repository>files page of your fork project, you can now see how far behind or ahead your fork's branch is from the upstream project. In a second iteration, we intend to make updating easy. Any feedback on that issue is welcome.
Next to such bigger efforts, we also spend capacity on smaller issues raised by customers as we have a long list of such and want to start burning these downs after having focused on GitLab.com stability and security for a long time.
In our milestone planning issues under our prioritization & Planning epic you find a detailed view of work done in each iteration. In the same epic, you also find our working list for prioritization.
This represents our roadmap for the next 3 to 6 months.
Framework for Source Code Rules
GitLab offers a number of controls that can be implemented as safeguards. These controls such as protected branches, approval rules, code owners' approvals, and many more can be put in place to enforce adherence to policies that ensure quality. A recent SUS study and other feedback suggest that users struggle to find the different controls and struggle to understand which settings interact how. Framework for Source Code Rules aims at making it easier and more intuitive to administer your Source Code management tool. To do so we are bringing the different controls together into one single place and will organize them on a per-branch basis.
The MVC: view source code rules organized by branches is currently being worked on. It enables viewing only.
After its release, we intend to add the ability to also edit the rules in this new branch-view. Beyond this, we intend to also move security approvals under branch rules.
Long-term we will consider also moving settings under the per-branch view that currently don't relate to branches but might benefit from attaching them to branches such as status checks or merge checks.
Improvements to the list of commits
This category is currently at the Loveable maturity level (see our definitions of maturity levels).
However, specific aspects are not yet loveable:
The primary performance indicator (PI) for our group is the number of unique users writing to a project Git repository. We want to ensure all the features in our group provide a great experience that ultimately will allow everyone to contribute more often. A great experience in our group is a critical starting point for this.
Aligning with our SaaS first and product depth direction, we are also working to make performance our secondary indicator (see related issue). The intent here is to track the most heavily used services in our group and track how they improve over time. We firmly believe speed is the killer feature and as such will work to provide a speedy experience to set a great stage for new and existing users.
See more detail in the Create:Source Code PI page section.
The Source Code category of GitLab offers the features where the creative process begins. Here authors will not only consume existing project contents but will also author new content that will eventually move through the DevOps lifecycle. Additionally, many of the features in Source Code are consumed in the Code Review stage of the software developement lifecycle. Consider the following examples:
Because of this close relationship, the Source Code Management group must work closely with the Code Review group in order to ensure the developer experience is cohesive and efficient. This experience is core to providing a great first impression for users.
Important competitors are GitHub and Perforce, and increasingly Azure DevOps.
For public open-source projects, GitHub is our primary competitor, with millions of active users having chosen GitHub before the first version of GitLab ever existed.
In most source code management capabilities, GitLab compares favorably to GitHub, the most notable exception being the maturity of forking workflows which GitHub pioneered. GitHub has a highly polished and fast product, which makes tasks like browsing and managing projects fast and easy.
For users of SVN (Apache Subversion) intending to migrate to Git, GitHub is a significant competitor, particularly because GitHub supports hosting SVN repositories.
Perforce competes with GitLab primarily on its ability to support enormous repositories, however, Perforce also competes on the basis of being a Centralized Version Control System. This means that Perforce not only supports granular write permissions but granular read permissions on a branch and file path basis. While fine-grained read permissions are important to some customers, large monolithic repositories may be split into smaller repositories allowing read controls and easier management.
Large file support (see Gitaly direction) is an ongoing area of interest because it blocks certain segments of software development from using Git.
Similarly, extremely large repository support (see Gitaly direction) is also an area of interest for the same reason.