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-07-07 |
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.
To be extended.
Fetch new upstream contents when fork is behind: Managing your fork just got easier. When your fork is behind, select Update fork to catch it up with upstream changes. When your fork is ahead, select Create merge request to contribute your change back to the upstream project. Both operations previously required you to use the command line.
See how many commits your fork is ahead (or behind) on your project's main page and at Repository > Files. If merge conflicts exist, the UI gives guidance on how to resolve them using Git from the command line.
Better display of tags and branches in commit detail view: In the commit detail view, you can now see at a glance the tag(s) a commit has been tagged with (if at all) and the list of branches that have the commit at the tip. This can for instance help you contextualize the commit with information from the tag (e.g. critical-hot-fix).
You can further expand the UI elements to see the list of tags and branches that contain the commit in their history. This helps you for instance to understand the list of branches a commit that introduced a bug has propagated to, to know in which you have to revert the commit.
Mirror specific branches only: Do you need to mirror a busy repository with many branches, but you only need a few of them? Limit the number of branches you mirror by creating a regular expression that matches only the branches you need.
Previously, mirrors required you to mirror an entire repository, or all protected branches. This new flexibility can decrease the amount of data your mirrors push or pull, and keep sensitive branches out of public mirrors.
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.
Report number of lines per language and/or 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. Counting the lines of code per language in a repository has shown to be a nice-to-have and can therefore not be prioritized against more important featuers on the roadmap above.
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: