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.
Last updated: 2021-01-07
| Section | Stage | Maturity | Last Reviewed |
|---|---|---|---|
| Dev | Create | Loveable | 2020-12-15 |
The Source Code Management direction page belongs to the Source Code group of the Create stage, and is maintained by Daniel Gruesso.
This direction is a work in progress, and everyone can contribute. Please comment and contribute in the linked issues and epics. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.
Source Code Management provides the core workflows and controls for teams to collaborate using Git to build great software, including protected branches, code owners, merge request approvals, and mirroring.
Source code management targets mainly software engineers but also anyone who is contributing to any types of project. To that end, we target all the user personas we describe in our handbook, with a special focus on the following:
Sasha (Software Developer): targets full time contributors to all types of projects (commercial, OSS, data science, etc.). These users expect and need a high level of reliability and speed in their interactions with both project files and Git.
Delaney (Development Team Lead): targets users who often times have elevated roles which allow for the management of project settings, such as access control, security, commit strategies, and mirroring.
Devon (DevOps Engineer): targets engineers tasked with supporting and enabling software teams. Their tasks often revolve around platform creation and maintenance, where GitOps] workflows are crucial.
Rachel (Release Manager): targets users in charge of ddeciding which changes will be shipped as a unit. This is an important part of the release cycle which allows effective packaging and deployment.
Simone (Software Engineer in Test): targets users who must review the code in order to ensure all relevant tests are created, stored, and run as part of the project. They rely of the speed and performance of both Git and GitLab.
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 is need. This is true whether using a single monolithic repository, or spread across numerous smaller services and libraries.
Teams require the controls to protect production while making it easy for everyone contribute. This means providing more granular and dynamic controls so that low risk changes can be made easily, and only the highest risk changes require the strictest controls.
Building software we stand not only on the shoulders of the giants of Computer Science, but of our contemporaries: the authors and maintainers of open source software. Private companies have been beneficiaries, contributors, and authors of these projects, yet lack of controlled workflows prevent more upstream contributions.
Upstreaming contributions from private repository to a public upstream should simple and safe, even for conservative organizations. Whether the upstream repository is on the same GitLab server, is hosted on GitHub.com, or upstream contributions managed via a mailing list. GitLab should enable collaboration between isolated and firewalled teams.
In progress: Support selecting code owners sections as required approval rule
Now that code owners is represented in the database, new powerful workflows are unlocked. Among them, the ability to use code owners sections in approval rules as well as mark certain sections or rules as optional. Code owners sections allow each team to configure their own code owners independently. The section rules may be used for shared paths so that multiple teams can be added as reviewers, ensuring the right groups are reviewing relevant code will help with increased code quality, while getting feedback/reviews from the right reviewers will lead to increased efficiency.
Support for addressing sections in approval rules allows greater control and flexibility for managing who can approve changes to a particular section in the codebase.
In progress: Manage/reduce repository size
Managing & reducing repository storage is an important part of resource management/consumption of Git repositories. The ability to easily cleanup and receive feedback on related actions from the GitLab GUI is an important part of managing your source code.
In progress: Improve commit list and details
Providing relevant metadata for commmits allows developers and release managers to determine which merge requests carry the relevant code for a certain change. This is an important part of the release cycle which allows effective packaging and deployment.
Next: Forking improvements
Forking workflows are important for open source projects on public instances like GitLab.com, but they are also used for private projects on GitLab.com and elsewhere. There are a range of significant shortcomings in the forking workflow that should be resolved. Forking workflows should be fully supported in GitLab so that they can be used by open source projects and enterprises, public or private.
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.
This category is currently at the Loveable maturity level (see our definitions of maturity levels).
However, specific aspects are not yet loveable:
Important competitors are GitHub and Perforce, and increasingly Azure DevOps.
For public open source projects, GitHub is our primary competitor, with millions of active users having chosen GitHub before the first version of GitLab ever existed.
In most source code management capabilities GitLab compares favorably to GitHub, the most notable exception being the maturity of forking workflows which GitHub pioneered. GitHub has a highly polished and fast product, which makes tasks like browsing and managing projects fast and easy.
For users of SVN (Apache Subversion) intending to migrate to Git, GitHub is a significant competitor, particularly because GitHub supports hosting SVN repositories.
Perforce competes with GitLab primarily on it's ability to support enormous repositories, however, Perforce also competes on the basis of being a Centralized Version Control System. This means that Perforce not only supports granular write permissions, but granular read permissions on a branch and file path basis. While fine grained read permissions are important to some customers, large monolithic repositories may be split into smaller repositories allowing read controls and easier management.
Large file support (see Gitaly direction) is an ongoing area of interest because it blocks certain segments of software development from using Git.
Similarly extremely large repository support (see Gitaly direction) is also an area of interest for the same reason.
The most frequent category of request is for improved support for finer grained controls, so that policies can be enforced at key points in the workflow, and more permissive permissions can be granted at other times.
Other items of frequent interest include:
