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 | 2024-06-18 |
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:
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:
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.
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:
In Progress: Branch Rules Editing MVC: Branch rules editing will enable users to edit branch-level rules in one single place. This will allow us to subsequently move certain rules to the branch level, enabling more flexibility for configuring target branches.
Completed: Commit signing for GitLab UI commits (Self-Managed and GitLab Dedicated): You can now configure your self-managed instance with a signing key, a committer name, and email address to sign web and automated commits.
In Progress: Commit signing for GitLab UI commits on GitLab.com: Once this is introduced, we will sign web commits and automated commits made by GitLab for all GitLab.com projects.
In Progress: Beyond Identity Integration post-MVC improvements
In Progress: Improve support for Git LFS: Git LFS performance improvements
Later: Introduce a new merge strategy option git merge –squash: Introduce git merge –squash. This is part of our plans to enable users to squash merge MRs without merge commit.
Later: Better support for large binary files: Better Support for Large Binary Files
Later: Group-level snippets
Later: Continue to improve experience with CODEOWNERS: CODEOWNERS Improvements
Introduce git merge –squash. We will introduce a new merge strategy option git merge –squash as part of our plans to enable users to squash merge MRs without merge commit.
Pure SSH LFS Transport: Driven by community contributors. Users will now be able to use LFS with SSH as the LFS transport mechanism instead of HTTPS. Some environments are forbidden from using HTTPS. This will enable customers who could not previously use LFS to do so.
Authentication and commit signing with SSH certificates on GitLab.com: Previously, Git access control options on GitLab.com relied on credentials set up in the user account. Now you can set up a process to make Git access possible using only SSH certificates. You can also use these certificates to sign commits.
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:
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.
All GitLab users use the Source Code category. The more intensive users are the following: