Version Control Market Share 2026: Git, SVN, Perforce and the Data

Git dominates. In Stack Overflow's 2022 Developer Survey, the latest independent survey that asked, 93.87% of 71,379 respondents used Git, 5.18% Subversion (SVN) and 1.13% Mercurial. No newer independent survey asks the question. Game studios and other binary-heavy teams report a very different mix, led by Perforce.

This post lays every dataset we could verify side by side, says who ran each one and who answered it, and explains why they disagree. It ends with what the split means for a security or platform team whose tools need to cover every repository the company actually ships from, not just the ones on a Git host.

Key takeaways

• The newest independent number is from 2022. Stack Overflow's 2023, 2024 and 2025 results pages show no version control question. Pages presenting 93.87% as a "2025" figure are repeating 2022 data.
• Git rose fast, then flattened. Stack Overflow: 69.3% (2015), 87.2% (2018), 93.87% (2022). SVN fell from 36.9% to 16.1% to 5.18%.
• Professionals lean harder on Git. 96.65% of professional developers named Git in 2022; 1.38% used no version control.
• JetBrains agrees. Its 2021 survey put Git at 93% and Subversion at 7%, per The Register.
• Games are the exception. Perforce's own 2024 survey put its Helix Core at 51% in its sample. That is a vendor survey.
• Public repository counts favour SVN. Open Hub's last verified snapshot (March 2018) had Git at 48.66% and Subversion at 39.84% of indexed repositories.
• No authoritative revenue share exists, and we do not invent one.
• Security tooling must cover the non-Git estate, which is often the oldest code you ship.

Who uses Git, SVN and Mercurial, per the latest independent survey?

The most recent independent, cross-industry survey with a published version control share is the Stack Overflow Developer Survey 2022. Respondents could select more than one system, so shares add up to more than 100%. The question offered Git, SVN, Mercurial and "I don't use one". Stack Overflow's own blog later noted that Perforce "didn't even register on our survey", even though interviewees mentioned it.

Stack Overflow 2022: share by respondent group

Source: Stack Overflow Developer Survey 2022, version control section, figures as shown on survey.stackoverflow.co/2022. Counts in brackets are respondents.

SVN is a professional's tool: its share among working developers (5.96%) is four times its share among learners (1.41%). People meet Subversion inside an existing company codebase, not in tutorials. Learners arrive with Git (81.87%) or with nothing (17.18%), almost never with Subversion.

Why the "2025" figures you see online are really 2022

Pages quoting Git at 93.87%, SVN at 5.18% and Mercurial at 1.13% under a 2025 or 2026 heading are repeating the Stack Overflow 2022 figures. We fetched the 2023, 2024 and 2025 results pages and found no version control question on any of them. The 2025 page lists GitHub under collaboration tools, which is a different question.

So the honest 2026 statement is: the latest independent survey number for Git, SVN and Mercurial is from 2022. It is the best available, but it is not current data.

How has the share moved since 2015?

We verified a version control question on Stack Overflow's own pages for 2015, 2018 and 2022. Options and sample sizes changed, so read the trend as direction, not a precise time series.

Stack Overflow trend, all respondents

Sources: survey.stackoverflow.co/2015, /2018 and /2022. All questions allowed multiple answers.

The 2015 sample for this question (16,694) was far smaller than later years, so part of the jump to 87.2% is a change in who answered. The 2018 figures also circulate in two versions: professional developers reported Git 88.4%, SVN 16.6% and Mercurial 3.7% of 69,808, while all respondents reported 87.2%, 16.1% and 3.6% of 74,298. Some secondary pages pair the professional percentages with the all-respondents total.

What the trend says

Subversion lost about 32 points in seven years; Mercurial about 7. Team Foundation Version Control was still at 10.9% in 2018 and was not offered by 2022, so we have no measured number for it after that. Git gained nearly 25 points, then added less than 7 from 2018 to 2022, which is what you expect near the ceiling.

For older context, Martin Fowler published a 2010 poll of 99 people on a Thoughtworks mailing list that rated tools rather than measuring use: Git had 99% approval, Mercurial 97% and Subversion 93%. Fowler warned the sample was small and narrow.

What does the JetBrains Developer Ecosystem survey show?

JetBrains sells IDEs, not a version control system, so we treat its annual survey as independent of VCS vendors, while noting that many respondents are JetBrains users and that it weights its data.

JetBrains figures we could verify

Sources: The Register's coverage of the 2021 report (for the Git and Subversion percentages and the 2020 comparison); JetBrains' own 2021, 2024 and 2025 report pages for respondent counts and fieldwork dates.

How the wording differs

Stack Overflow used one multi-select question. JetBrains asks about version control inside a long tooling survey, reports rounded percentages and also asks how people use it: The Register reported 67% used Git or similar tools from the terminal and 57% from an IDE. The Register also noted that 2020 targeted 18 countries while 2021 was global, so the rise from 90% to 93% partly reflects the change in sample frame.

Do JetBrains and Stack Overflow agree?

Broadly, yes. Both put Git in the low 90s in 2021 to 2022 and Subversion in single digits, and JetBrains' 7% for 2021 sits between Stack Overflow's 16.1% (2018) and 5.18% (2022). A secondary claim that JetBrains 2023 put Git at 87% could not be found on a JetBrains page, so we do not use it.

Why do game and real-time 3D studios report a different picture?

Every developer survey above under-samples the people who build games, film effects, automotive digital twins and chip designs. Those teams store huge binary files (textures, models, audio, video, design data) that do not merge, and they need many contributors, including artists who never touch a command line, to avoid overwriting each other's work. That pushes them toward centralised systems with exclusive file locking.

Perforce: vendor surveys, labelled as such

Sources: game industry library summary of the 2024 report; Perforce's 2026 press release and report page; Perforce's P4 product page.

The 51% is Perforce's own product share in a survey Perforce ran for an audience that overlaps its customer base. It is a real signal about games and real-time 3D, not an independent market share. The 2026 "94% adoption" is a different kind of number: the share of practitioners using any version control at all, which implies 14% used none in 2025 and 6% in 2026, against 1.38% of professional developers in Stack Overflow 2022.

Perforce now markets the product as P4, "P4 (Helix Core)" in its menu, and highlights exclusive file locking, proxy and edge servers, and scale to "petabytes of data, millions of files".

Unity Version Control (formerly Plastic SCM)

Unity describes Unity Version Control as "powered by Plastic SCM technology" and built for programmers, artists and designers. Its page highlights responsiveness with large binaries, "Smart Locks" that combine branching with file locking, and both centralised and distributed workflows. Unity publishes pricing (three free seats, then per-seat pricing) but no adoption figures. We found no independent survey that reports its share.

Why the developer surveys miss this

Developer surveys reach software engineers, not the artists who make up much of a studio. Engineers there often use Git for tools and Perforce for the game, and tick Git in a multi-select question. So "Git 94%" and "most studio bytes in Perforce" can both be true.

How big is the hosted Git world?

GitHub's Octoverse 2025 covers 1 September 2024 to 31 August 2025 and counts GitHub only, not other Git hosts or self-hosted servers.

GitHub Octoverse 2025 headline numbers

Source: GitHub Octoverse 2025, published 28 October 2025 and updated 28 February 2026.

This is the size of one Git host, not Git's share. It shows the Git population growing by tens of millions a year, and the private share of contributions (about 81.5%) shows why public repository counts undercount what companies run.

What do public repository counts say, and why are they biased?

Open Hub indexes public open source projects. Its comparison page returned HTTP 403 to our fetch on 23 October 2026, so we used an independent tracker of its numbers whose latest data point is March 2018.

Open Hub indexed repositories, last verified snapshot (15 March 2018)

Source: oyvholm/openhub-repositories on GitHub, status file, tracking Open Hub's repository comparison since 5 August 2014.

Why this disagrees with the surveys

In 2018 Stack Overflow had SVN at 16.1% of developers while Open Hub had it at 39.84% of indexed repositories. Repositories are not people; Open Hub indexes projects registered years ago, many of which started on SVN or CVS; dead projects are not pruned; and private code is invisible. Against about 395 million public repositories on GitHub alone in 2025, Open Hub's 820,865 is a small, aging sample, useful mainly as history.

Where do Fossil, Sapling and Jujutsu fit?

None of these publishes usage figures, and no independent survey we found asks about them. Here is what each project says about itself.

Newer and niche systems: what the projects say

Sources: fossil-scm.org; github.com/facebook/sapling; github.com/jj-vcs/jj.

GitHub stars measure attention, not use. More telling is that Sapling and Jujutsu are both Git-compatible: the newest tools sit on top of Git rather than compete with it, so a team using Jujutsu against a Git remote still counts as Git to its host and its tooling. Fossil is the fully separate exception, with no published usage number.

Where does Anthropic's Scion fit?

Scion is a single-company data point, not a market product. In "Redesigning source control at Anthropic" (13 October 2026, updated 15 October), Anthropic describes Scion as its in-house version control system and says it migrated its monorepo off Git in five months. Anthropic states Scion "is by no means a suitable replacement for git for general use". It is not released. Community projects using the name are unaffiliated, not Anthropic software.

Scion scale figures, per Anthropic

Source: Anthropic Engineering, "Redesigning source control at Anthropic" (13 October 2026, updated 15 October 2026).

The design is server-authoritative: the server computes history, merges and rebases, and clients keep a bounded cache with sparse and virtual checkouts. Anthropic credits Sapling's Mononoke server and its Bonsai data model. The post describes repository-level and per-directory permissions; it does not name a hash algorithm or describe signing.

Why include it? It shows where pressure on Git comes from in 2026: automated workloads, not a rival tool. Octoverse's 518.7 million merged pull requests a year average about 1.42 million a day across GitHub; Anthropic's September rate is about 2% of that from one company. Units and periods differ, so treat it as order of magnitude only. Anthropic says it wants to work with the major Git hosting platforms and the open source community to bring ideas to Git; no integration has been announced.

Ranked: version control share by segment

Each row uses the most recent verified figure for its segment. Rows answer different questions and are not comparable to each other.

Segments are ranked by Git's share. Git leads in five of six; the exception is a vendor's survey of its own core market, and the narrowest Git lead is in the oldest dataset.

Ranked: each system's most recent independent developer share

Source: Stack Overflow Developer Survey 2015, 2018 and 2022 (all respondents).

Rows 4 to 6 rank below Mercurial despite larger percentages because their figures are older and Stack Overflow dropped them from the list, which is itself evidence of a small share.

Where the datasets disagree, and why

How we measured

1. Primary pages first. We fetched each publisher's own page on 23 October 2026: Stack Overflow 2015, 2018 and 2022 to 2025; JetBrains 2021, 2024 and 2025; Perforce's 2026 press release, report and product pages; Octoverse 2025; the Fossil, Sapling and Jujutsu pages; Anthropic's Scion post.
2. Secondary sources only where the primary did not render the number. JetBrains 2020 and 2021 percentages come from The Register; Open Hub figures from an independent tracker (Open Hub returned HTTP 403); Perforce 2024 from a public summary (full report gated).
3. We checked whether newer surveys asked. No version control question appeared on Stack Overflow 2023 to 2025 or JetBrains 2024 and 2025 pages. That shows the published headline results lack it, not that no data exists anywhere.
4. We labelled source types. "Independent" means run by an organisation that does not sell a version control system; "vendor survey" means one that does. Repository indexes and hosting reports count repositories or activity, not people.
5. We did not combine or average percentages across sources, did not estimate a revenue share, and used GitHub stars only as an attention signal.

Known limits: survey samples self-select; JetBrains' sample includes many JetBrains users even after weighting; the 2015 Stack Overflow sample was small; Open Hub figures are eight years old.

What should a security or platform team take from the split?

"Everything is in Git now" is close to true for new code and false for the full estate. The SVN repositories and Perforce depots that remain tend to hold the oldest, least reviewed code, the most likely to carry unpatched dependencies.

• Inventory by system, not by host. A list of Git host organisations is not an inventory of your source code.
• Security tooling integrates with Git hosts first. Non-Git repositories need another route: scanning a working copy or build output, or ingesting an SBOM.
• The clients are software too. Git's CVE-2025-48384, published 8 July 2025 with a CVSS 3.1 score of 8.0, could let a crafted repository run a hook during a recursive clone; fixed releases include 2.43.7, 2.44.4, 2.45.4, 2.46.4, 2.47.3, 2.48.2, 2.49.1 and 2.50.1. The Apache Subversion security page lists CVE-2024-46901 (argument injection on Windows, affecting 1.0.0 through 1.14.4) and CVE-2024-45720 (a mod_dav_svn denial of service). For more, see argument injection in Git and Mercurial, and for a Perforce example, CVE-2024-0325 in Perforce Helix sync.
• Restrict which version control tools your build calls. Go's GOVCS setting is one example; see GOVCS explained.
• Plan for host outages. See can your team ship if your Git host is down.

Coverage map: how each kind of estate can be scanned with Safeguard

Safeguard does not offer native SVN, Perforce, Mercurial, Fossil or Unity Version Control integrations. What it scans is the content: manifests, lockfiles, container images and SBOM files. That works the same whatever system stored them.

Step by step: inventory and scan a mixed version control estate

This walkthrough assumes a Linux or macOS build host. Adjust paths for your environment.

1. Find working copies on a host

Each system leaves a marker in the working copy. Git uses .git, Subversion .svn, Mercurial .hg, Jujutsu .jj, Sapling .sl and Plastic or Unity Version Control .plastic. Fossil uses a .fslckout file (or _FOSSIL_ on some platforms). Perforce has no fixed marker; many teams use a .p4config file named by the P4CONFIG setting.

# Directories that mark a working copy
find /srv /opt /home -xdev -maxdepth 6 -type d \
  \( -name .git -o -name .svn -o -name .hg -o -name .jj -o -name .sl -o -name .plastic \) \
  -prune -print 2>/dev/null | sort > vcs-dirs.txt

# Files that mark a Fossil checkout or a Perforce workspace config
find /srv /opt /home -xdev -maxdepth 6 -type f \
  \( -name .fslckout -o -name _FOSSIL_ -o -name .p4config \) \
  -print 2>/dev/null | sort > vcs-files.txt

# Count by system
sed -E 's#.*/##' vcs-dirs.txt vcs-files.txt | sort | uniq -c

2. Record client versions

git --version
svn --version --quiet
hg --version | head -1
p4 -V | tail -2
fossil version
jj --version
sl --version

Compare the Git version against the fixed releases for any Git advisory you track. For CVE-2025-48384 the fixed releases listed by the Git project are 2.43.7, 2.44.4, 2.45.4, 2.46.4, 2.47.3, 2.48.2, 2.49.1 and 2.50.1 or later.

3. Take a clean snapshot of non-Git code

For Subversion, export a clean tree (no .svn metadata) and record the revision you scanned:

REPO=https://svn.example.org/repos/app/trunk
REV=$(svn info --show-item revision "$REPO")
echo "$REV" > scanned-revision.txt
svn export --quiet -r "$REV" "$REPO" /tmp/app-snapshot

For Perforce, sync a dedicated scan workspace and record the change number:

export P4CLIENT=ci-scan-ws
p4 sync -q //depot/app/main/...
p4 changes -m1 "//depot/app/main/...#have" > scanned-change.txt

Recording the revision or change number matters. When a finding comes back weeks later, you need to know exactly which state of the code it describes.

4. Scan the snapshot

cd /tmp/app-snapshot
safeguard scan --dir .
ls ./output    # results are written as JSON here

If the code ships as a container image, scan the image as well, because the image includes operating system packages the source tree does not:

safeguard scan --image registry.example.org/app:1.4.2

If another team already produces an SBOM for the build, scan that:

safeguard scan --sbom app.cdx.json

To run these scans on your own hardware without giving any service direct access to the repository, the local runner pairs a machine you control with your Safeguard account; the demo at the end of this post shows that setup.

5. Optional: mirror SVN into Git, and keep the inventory current

Git ships git svn if you want Git-host tooling to see a Subversion repository:

git svn clone --stdlayout https://svn.example.org/repos/app app-git

A mirror is a second copy with its own credentials and drift; for dependency scanning alone, step 4 is simpler. Then rerun steps 1 and 2 on a schedule and diff the results, because a new .svn directory on a build host never shows up in a Git host's settings.

Common mistakes

• Quoting 2022 survey numbers as 2025 or 2026 data. The Stack Overflow figures are from 2022. Say so.
• Mixing groups or adding multi-select shares. 2018's 88.4% is professional developers; 87.2% is everyone. Shares sum past 100%.
• Treating a vendor survey as a market share. Perforce's 51% is its own product's share in its own sample. Useful, not neutral.
• Reading repository counts as user counts. Open Hub's 39.84% for Subversion counted old public repositories, not developers.
• Calling Scion a Git alternative you can adopt. It is internal to Anthropic and not released. Unaffiliated projects using the name are not Anthropic's.
• Assuming your security tools see every repository. Integrations that hook into Git hosts will not see SVN servers or Perforce depots.
• Forgetting the clients and servers themselves. Old SVN servers and outdated Git clients carry their own CVEs.

Fix it without waiting for upstream

Market share is the reason this matters for security: whatever system holds your code, the open source dependencies inside it are the same packages with the same CVEs. The difference is only how easily your tools reach them.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

What is the market share of Git in 2026?

No independent survey has published a 2026 figure. The latest independent cross-industry number is Stack Overflow's 2022 survey: 93.87% of all respondents and 96.65% of professional developers used Git. JetBrains' 2021 survey put Git at 93%. Expect the true share among developers to be at least that high today, but no newer independent measurement exists.

Is SVN still used in 2026?

Yes, but by a small and shrinking share of developers. Stack Overflow 2022 recorded 5.18% of all respondents and 5.96% of professional developers using SVN, down from 36.9% of respondents in 2015. The Apache Subversion project still publishes security advisories, including CVE-2024-46901 and CVE-2024-45720.

Did Stack Overflow stop asking about version control?

The 2023, 2024 and 2025 survey results pages we fetched on 23 October 2026 show no version control question. The 2022 survey is the most recent one with published Git, SVN and Mercurial figures.

What version control do game studios use?

Perforce's own 2024 State of Game Technology survey put its Helix Core product at 51% across industries in its sample, and Perforce says it is trusted by 19 of the top 20 AAA studios. Both are vendor figures. Unity Version Control (formerly Plastic SCM) also targets game teams. Many studios use Git for code tools and Perforce for game assets.

Why does Perforce not show up in developer surveys?

Developer surveys mostly reach software engineers, and binary-heavy teams include many artists and designers who do not answer them. Stack Overflow last listed Perforce in 2015, at 3.3%, and its blog said Perforce "didn't even register" in 2022.

Is Jujutsu replacing Git?

Jujutsu is Git-compatible and uses Git repositories as its default storage, so it changes the client experience rather than replacing Git storage. Its GitHub repository had about 32,200 stars when we checked, but the project publishes no usage figures and no independent survey measures it.

What is Anthropic's Scion, and can I use it?

Scion is Anthropic's internal version control system, which replaced Git for its monorepo in 2026. Anthropic says it is not a suitable replacement for Git for general use, and it has not been released. Projects on GitHub using the name are unaffiliated.

Is there a revenue market share for version control software?

We found no authoritative one. Most version control usage runs on free and open source tools, and the commercial products sit inside larger platforms, so revenue figures from third-party pages are estimates without published methods.

See how Safeguard would help

Your code may live in more than one version control system, and security checks have to reach all of them. These demos show the parts of Safeguard that work on files and builds wherever they came from. Download the apps at safeguard.sh/download and read the CLI documentation to try it on your own code.

The first demo is a real CLI session. It installs the CLI, opens the interactive terminal, asks it to fix a lodash CVE in a repository, and shows it reading the finding, asking before each command, editing package.json, running the install and tests with approval and pushing nothing. The same session works on an SVN export or a Perforce workspace, because it reads the files on disk.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code, then scans from the terminal. This is the route for repositories that no Git host integration can see, such as an on premises Subversion server or a Perforce depot that never leaves your network.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Because the Safeguard platform shows which projects contain a given component and version, this gives one view across projects that came from different version control systems.

Click through it at your own pace, or open it full screen.

Related: SBOM incident response: finding affected products fast and the Safeguard CLI as a security aware coding assistant.

Quick check

Sources

• Stack Overflow Developer Survey 2022
• Stack Overflow Developer Survey 2018
• Stack Overflow Developer Survey 2015
• Stack Overflow Developer Survey 2023
• Stack Overflow Developer Survey 2024
• Stack Overflow Developer Survey 2025
• Stack Overflow blog: Beyond Git, the other version control systems developers use (January 2023)
• The Register: JetBrains developer survey 2021 (July 2021)
• JetBrains State of Developer Ecosystem 2021
• JetBrains State of Developer Ecosystem 2024
• JetBrains State of Developer Ecosystem 2025
• Perforce press release: State of Real-Time Workflows 2026 (vendor survey)
• Perforce: State of Real-Time Workflows report page (vendor survey)
• Perforce State of Game Technology 2024 summary (vendor survey)
• Perforce P4 product page
• Unity Version Control
• GitHub Octoverse 2025
• oyvholm/openhub-repositories, tracking Open Hub repository counts
• oyvholm/openhub-repositories status file (snapshot 15 March 2018)
• Martin Fowler: Version Control Tools survey (2010)
• Fossil SCM
• Sapling on GitHub
• Jujutsu on GitHub
• Anthropic Engineering: Redesigning source control at Anthropic (13 October 2026)
• Git security advisory GHSA-vwqx-4fm8-6qc9 (CVE-2025-48384)
• Apache Subversion security advisories

Last reviewed: 23 October 2026. Survey publishers add and drop questions each year; check the linked pages for any newer version control figures.