Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Source Code Management

Source Code Management

Last updated: 2021-03-16

Section Stage Maturity Last Reviewed
Dev Create Loveable 2020-12-15

Introduction and how you can help

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.

Overview

Source Code Management provides the core workflows and controls for teams to collaborate using Git to build great software, including repository view, protected branches, code owners, merge request approvals, and mirroring.

Target Audience

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:

Where we are Headed

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 a must. 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.

When building software, teams greatly benefit from using open-source projects and may even submit contributions upstream. However, the balance of contribution vs. consumption is askew, partly because of a lack of controlled upstream workflows. Particularly from closed projects.

Upstreaming contributions from private repositories to a public upstream should be simple and safe, even for conservative organizations. Whether the upstream repository is on the same GitLab server, is hosted on GitHub.com, or managed via a mailing list.

Critical Product Principles

GitLab maintains a set of Product Principles, some of which are more critical to be aware of in the Source Code category. Here they are, and why the are critical:

What's Next & Why

What is Not Planned Right Now

Maturity Plan

This category is currently at the Loveable maturity level (see our definitions of maturity levels).

However, specific aspects are not yet loveable:

Competitive Landscape

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 its 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.

Analyst Landscape

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.

Top Customer Success/Sales issue(s)

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.

Top user issue(s)

Top dogfooding issues

Top Vision Item(s)

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license