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.
| Stage | Create |
|---|---|
| Maturity | Loveable |
| Content Last Reviewed | 2023-12-01 |
The Source Code Management direction page belongs to the Source Code group of the Create stage, and is maintained by Derek Ferguson, who can be reached at [email protected].
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 below, or to any other issues or 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:
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.
CODEOWNERS file syntax and format validation: You can now see in the UI if your CODEOWNERS file has syntax or formatting errors. Being able to specify code owners offers great flexibility, allowing multiple file locations, sections, and rules to be configured by users.
With this new syntax validation, errors in your CODEOWNERS file will be surfaced in the GitLab UI, making it easy to spot and fix issues.
The Source Code group is not investing in the following opportunities in the immediate future:
Limiting which branches a user can read in a Git repository is possible in a basic sense, by only advertising a subset of refs, but it is not possible to guarantee that unreachable objects will not be sent to the client. This means that branch read access controls would be very weak, since they could not prevent exfiltration of data they do not have permission to read.
Path-level read access controls
From a commit, Git expects all trees and blobs to be reachable. Although Git supports partial clone and spares checkout, which allow data to be excluded from fetch and checkout, Git expects to be able to fetch missing objects on demand. Deliberately excluding objects by path is likely to cause unexpected failures.
Report number of lines per contributor
Research has shown that reporting the lines of code contributed could hurt individual users as this has a tendency to be misused as a false measure of contribution.
Improvements to Project Templates
Due to other priorities, we won't be able to progress Project templates in 2023.
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
This information is maintained on this internal handbook page
This information is maintained on this internal handbook page
This information is maintained on this internal handbook page
This category is currently of Loveable maturity level (see our definitions of maturity levels).
We plan to re-assess the maturity level in FY24-Q1.
All GitLab users use the Source Code category. The more intensive users are the following: