Category Direction - Source Code Management

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.

Source Code Management
Introduction and how you can help
Strategy and Themes
1 year plan
Best in Class Landscape
Maturity Plan
Target Audience

Source Code Management

Stage	Create
Maturity	Loveable
Content Last Reviewed	`2025-01-28`

Introduction and how you can help

Thanks for visiting the category direction page on Source Code Management. The Source Code Management direction page belongs to the Source Code group of the Create stage, and is maintained by Marie-Christine Babin.

This direction page is a work in progress, and everyone can contribute:

Please comment and contribute to issues linked througout this page or contained in our category epic. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.
If you would like to share your feedback directly or schedule a video call, please reach out directly to Marie-Christine Babin via email.

Strategy and Themes

Source Code Management (SCM) is a foundational practice in software development. Building great software depends on teams working well together. Teams can rarely be divided into areas of complete independence.

GitLab's vision for Source Code Management is the following: Managing code and data with GitLab is a practice that ultimately sparks collaboration between all team members, by centralizing the sharing and synchronization of both code and data securely, efficiently and intuitively, regardless of the file type or size, making it easy to track, compare and revert changes and understand how code and data evolves over time.

This vision stands in support of GitLab's mission to make it so everyone can contribute. Teams in industries such as game development, automotive, healthcare, engineering, construction and architecture, and teams working with datasets in machine learning, have dependencies on code and data being tightly coupled to be able to iterate efficiently. As per our GitLab values, we believe iteration enables results and efficiency. Facilitating collaboration for teams iterating with both code and data will help them iterate with less friction, enabling them to achieve results more efficiently.

In support of GitLab's vision for Source Code Management, our strategy is to enable scale across team management, repository size and file size. This strategy stands on 3 strategic pillars and one foundational pillar:

Strategic Pillars

Easy administration for large teams: Scale Source Code Management to large teams efficiently and intuitively.
High performance and better collaboration with large binary files: Handle large binary files effortlessly and collaborate seamlessly between developers and other team contributors, such as artists and designers, to support GitLab's mission to make it so everyone can contribute.
High performance and streamlined workflows with large repositories: Easily manage and collaborate with large repositories, including monorepos.

Foundational Pillar

Usability at scale: Manage source code with confidence with easy and intuitive workflows.

Source Code Management Strategy 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.~

Challenges

GitLab's Source Code Management builds on top of Git. Git is the leading Version Control System (VCS). It excels at tracking changes in source code and makes it easy and transparent to merge changes from different developers into one code base. Yet, neither Git nor GitLab SCM are perfect. Here are the current main shortcomings:

GitLab's SCM UX, has shown to be partly unintuitive. For instance, controls to enforce rules are hard to discover, understand and manage at scale.
Git is not particularly good at handling binary files. While Git Large File Storage (LFS) aims to address this, it is often deemed not suitable for use cases where teams iterate with a large amount of data such as game development, digital twins development (found in industries such as automotive, healthcare, engineering, construction and architecture) and for teams leveraging machine learning models with large datasets.
Performance can be impacted when repositories become exceptionally large (even if they do not contain binary files), including for monorepos which are used in several large tech companies. Partial clone addresses some of these issues.

1 year plan

Feature Enhancements

In Progress: Branch rules for Squash Settings
In Progress: Exempt specific files from CODEOWNER rules
In Progress: Add support for mailmap configurations
In Progress: Support ignoring commits in blame (blame.ignoreRevsFile)

UX Improvements

In Progress: Directory and single file pages improvements
In Progress: Improved validation support for CODEOWNERS

Performance & Reliability Improvements

In Progress: Improve support for Git LFS: Git LFS performance improvements
In Progress: Approvals rule re-architecture
In Progress: Reusable Rapid Diffs Architecture

Diffs are at the center of the code comparison within GitLab. We're working on a new architecture for diffs that improves performance and allows us to build more features on top of them.

What is next for us

Branch rules for Merge Methods

Introducing more flexible merge method options to support a variety of workflows is a critical pillar in source code management. We're evaluating how to introduce more flexible merge method configuration as well as exploring related work to improve fast-foward merges and make squashed merges more straighforward.
Commit signing for GitLab UI commits on GitLab.com: We are planning for the rollout of commit signing for GitLab UI commits on GitLab.com now that the feature has been delivered for Self-Managed and GitLab Dedicated. Once this is introduced, we will support signing web commits and automated commits made by GitLab for all GitLab.com projects.
Provide support for internal projects with other teams:
- Disaster Recovery Working Group
- GitLab Cells

What we are currently working on

Providing support for internal projects with other teams:
- GitLab Cells

What we recently completed

Other important issues recently delivered by the group can be seen in this list.

What is Not Planned Right Now

The Source Code group is not investing in the following opportunities in the immediate future:

Branch read access controls
- 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.

Best in Class Landscape

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.

Key Capabilities

This information is maintained on this internal handbook page

Roadmap