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-04-11 |
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 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.
To be extended.
Branch rule overview: All branch-related protections now display on a single page. To see a unified list of your branches and all their protection methods, go to Settings > Repository > Branch rules. Each branch shows the merge request approvals, security approvals, protected branches, and status checks configured for it. Previously, these settings were grouped by type, making it tough to see a holistic view of a specific branch’s protections.
Better display of tags in commits list view: Identifying commits that have been tagged just got simpler. View the commits list at Repository > Commits to see commits with their tags attached. This view helps you understand what commits have been added since a tagged release commit.
Require multiple approvals from CODEOWNERS: You can now precisely define for which files, file types, or directories approval has been designated as optional, required approval by 1 user or required approval by multiple users. The latter being the new improvement of CODEOWNERS.
So far, if you needed to require multiple approvers be it for compliance reasons or other reasons, you could only do so with an approval rule. However, unlike CODEOWNER approvals, approval rules apply to entire branches and cannot be refined to apply to specific parts of your code base. So, the multiple approvals would have also been required for changes that do not need a high level of scrutiny leading to unnecessary reviews. See documentation.
More control over your SSH connections with gitlab-sshd: gitlab-sshd is a standalone SSH server, written in Go, that provides more insight and control than OpenSSH. It's lightweight and contains minimal external dependencies. If you host a self-managed instance, switching from OpenSSH to gitlab-sshd gives you metrics collection, detailed logging, and graceful shutdowns for SSH connections. Unlike OpenSSH, it supports the PROXY protocol and can pass on the original IP address when operated behind a proxy. This enables you to restrict SSH access by IP address when your instance is operated behind a proxy.
GitLab.com has used gitlab-sshd since 15.2, and 100% of the SSH traffic passes through gitlab-sshd. To learn more, read this blog post. To understand how to enable it refer to the documentation.
gitlab-sshd began as a community contribution from @lorenz. Thank you very much for your contribution!
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.
Improvments 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: