Почему Git победил Mercurial, Bazaar и остальных

В 2005 году появились три DVCS почти одновременно: Git (April), Mercurial (April) и Bazaar (March). У всех была distributed-модель, у всех были атомарные коммиты, snapshots и поддержка веток. По многим параметрам Mercurial был технически приятнее — у него был чище UI, продуманные команды, лучшая документация.

Но к 2020 году Git занял 90%+ рынка. Mercurial удержали для себя Meta и Mozilla (потом и они мигрировали). Bazaar умер около 2017 года. Почему?

В этом уроке разберём, почему именно Git выиграл — не только технически, но и за счёт удачного стечения обстоятельств.

Технические причины победы Git

1. Скорость

Linus Torvalds написал Git с одним требованием: «должен работать с Linux kernel» — а это ~50 тысяч файлов, миллионы коммитов, тысячи параллельных веток. На таких репозиториях Mercurial был в разы медленнее Git на большинстве операций.

Числа примерные, но порядок верный. На маленьких репо разницы нет. На больших — Git выигрывает на порядок.

Почему? Linus оптимизировал каждую операцию под максимальный throughput. Git написан на C, использует mmap для objects, packfiles для эффективного хранения. Mercurial написан на Python+C, медленнее на старте каждой команды. Bazaar — на Python, ещё медленнее.

2. Простая модель данных

Это парадокс: пользовательский интерфейс Mercurial был проще, но внутренняя модель данных Git была проще.

В Git всего 4 типа объектов: blob (содержимое файла), tree (содержимое директории), commit (snapshot + metadata), tag (именованная ссылка). И всё. Любая операция сводится к чтению/созданию этих объектов.

В Mercurial были revlog (специальный формат хранения с дельтами), manifest (аналог tree), changesets (аналог commit), плюс набор внутренних абстракций для веток. Внутренне сложнее.

Простая модель Git дала несколько преимуществ. Во-первых, легко писать инструменты: GitHub API, плагины для редакторов, hook-системы — всем легко работать с моделью «4 типа объектов». Во-вторых, легко дебажить: git cat-file -p <SHA> показывает содержимое любого объекта. Никаких загадочных бинарных форматов. В-третьих, легко учить: каждая команда Git, разобранная на уровне модели, становится понятной.

3. Дешёвые ветки

В Git ветка — это 41 байт: имя файла = имя ветки, содержимое = SHA коммита + newline. Файл лежит в .git/refs/heads/. Создание ветки = создание файла. Переключение = смена HEAD = изменение одного файла.

cat .git/refs/heads/main
# d4eb2c1f8a3b9e7c1f2a5b6c8d9e0f1a2b3c4d5e
# Это всё содержимое ветки main — один SHA

В Mercurial 0.x ветки были встроены в commit metadata — поле branch в каждом коммите. Переключение ветки требовало пересчитать состояние, и переименование ветки было невозможно (это часть истории коммита).

Mercurial 2.x добавил bookmarks — лёгкий эквивалент Git-веток. Но к тому времени многие команды уже перешли на Git, потому что в Git ветки «just worked» с самого начала.

Это привело к радикально разной культуре работы. В Git-проектах создаётся ветка на каждую задачу, и feature-branch workflow стал стандартом. В Mercurial-проектах ветки были редкостью, патчи шли через mq (Mercurial Queues) — отдельный набор инструментов.

4. Гибкость и низкоуровневость

У Git есть два класса команд:

• Plumbing (низкоуровневые): git hash-object, git cat-file, git update-ref, git read-tree, etc.
• Porcelain (высокоуровневые): git add, git commit, git log, etc.

Porcelain — это удобный интерфейс над plumbing. Любую сложную задачу можно решить через plumbing. Это давало гигантскую гибкость: например, GitHub Desktop, Sourcetree, GitKraken — все они под капотом просто вызывают plumbing-команды.

Mercurial был более «всё в одном» — без чёткого разделения plumbing/porcelain. Хорошо для UX, но менее гибко для tooling.

Не-технические причины: GitHub

Если бы решало только техническое превосходство, Mercurial вполне мог бы выжить — он действительно был приятнее в обычном использовании. Но в 2008 году появился GitHub, и судьба определилась.

Что было до GitHub

До 2008 года распределение open-source кода выглядело так:

Чтобы сконтрибьютить, нужно было: создать аккаунт на сайте проекта, разобраться с их workflow, скачать репозиторий, сделать патч, отправить по email maintainer-у, ждать ответа. Если хочется поправить два проекта — повторить процесс дважды.

Что сделал GitHub

GitHub запустился в апреле 2008 года. Tom Preston-Werner, PJ Hyett, Chris Wanstrath. Три ключевых идеи:

1. Unified hosting: один аккаунт, любое количество репозиториев.
2. Fork button: один клик — у вас есть копия проекта, с которой вы можете работать.
3. Pull Request UI: предложить изменения через веб-интерфейс с обсуждением, code review, статусами CI.

Контрибьюция стала тривиальной. К 2012 году GitHub был крупнейшим хостингом open-source в мире, к 2015 — стандартом де-факто. И GitHub поддерживал только Git.

Это и решило. Mercurial-проекты на Bitbucket существовали (Bitbucket изначально был Mercurial-only, потом добавил Git). Но Bitbucket был меньше GitHub раз в пять, а network effect (где больше людей — туда хочется идти) работал на GitHub.

В 2020 году Bitbucket выпилил поддержку Mercurial. В 2024 году даже Meta мигрировала. К 2026 году Mercurial — нишевая система для энтузиастов.

Сетевой эффект и культура

GitHub дал не только хостинг, но и культуру: README, lic̄енз, contributing guide, issues, milestones, releases. Все эти концепции стали общими для всего open-source. И все они привязаны к Git.

К 2020 году новички в IT учились контрибьюции прямо на GitHub, не задумываясь о Git как отдельной технологии. Так и было задумано: GitHub — социальная сеть для кода, Git — её движок.

Альтернативы GitHub в 2026

GitHub доминирует, но не один:

• GitHub (Microsoft с 2018) — крупнейший, default для open-source, 100M+ пользователей в 2026
• GitLab — основной конкурент, фокус на enterprise, CI/CD из коробки, можно self-host
• Bitbucket (Atlassian) — менее популярен, но интегрирован с Jira
• Gitea / Forgejo — open-source self-hosted альтернативы (русскоязычные проекты часто хостятся здесь после санкций 2022-2024)
• Codeberg — community-driven, на базе Forgejo
• Платформы РФ: GitFlic, GitVerse (от Сбера). Растут для российской аудитории.

Все они работают с Git. Migrate между ними — это git clone + git remote set-url + git push. Знание Git универсально, привязки к хостингу нет.

В команде, где вы будете работать как Junior DE, скорее всего будет GitHub или GitLab. Иногда self-hosted Gitea. Очень редко — что-то экзотическое.

Что это значит для вас

Вы учите Git как технологию, не GitHub как сервис. Это правильный фокус. Команды git push, git pull, git fetch работают одинаково на любом хостинге. UI Pull Request на GitHub vs GitLab vs Gitea отличается косметически. Логика та же.

Сам Git как технология останется с нами надолго. Mercurial и Bazaar умерли, но идея distributed VCS оказалась настолько правильной, что её альтернатив не появилось (если не считать экзотики типа Pijul или Sapling). В обозримом будущем Git — это VCS-стандарт.

В следующем модуле будем устанавливать Git и настраивать его — и наконец перейдём от истории и теории к практике.

Попробуй сам

Зайдите на GitHub и посмотрите профили популярных DE-проектов:

• https://github.com/apache/airflow — Airflow
• https://github.com/dbt-labs/dbt-core — dbt
• https://github.com/getredash/redash — Redash
• https://github.com/duckdb/duckdb — DuckDB

Посмотрите вкладки: Code, Issues, Pull Requests, Actions. Изучите README одного проекта. Это та экосистема, в которой вы будете работать.