В конце 2025 года одновременно возникли два импульса: резкий рост темпа коммитов из-за агентов и стремление заменить GitHub. На этом фоне появился целый ряд новых систем контроля версий — от Git-совместимых форджей до полных стеков, не основанных на Git. Автор описывает этот период как крупнейшую революцию в контроле версий с 2005 года.
Что именно изменилось
К концу 2025 года разные команды начали разрабатывать новые решения контроля версий, и стартапы, которые раньше не решались бросить вызов GitHub, стали пытаться создать «следующий GitHub».
Pierre выпустил улучшенные диффы и деревья как open source, чтобы любой мог усилить свои код-UI, а затем сосредоточился на code.storage — Git-фордже для агентной реальности.
Origin — полноценный Git-фордж от Cursor (теперь SpaceXAI) с pull requests и хостингом репозиториев, сфокусированный на производительности и надёжности.
GitButler — не новый фордж, а клиентская сторона с другим пользовательским опытом: работа над несколькими ветками одновременно вместо постоянного переключения между ними.
East River Source Control (ersc.io) выводит Jujutsu на рынок, используя другой backend, чем Git.
Diversion — не основанная на Git система с cloud-first workspacesрабочими пространствами, которые полностью версионируются на стороне сервера, без локальных клонов.
Oxen.ai делает контроль версий для больших AI-датасетов и не участвует в той же гонке форджей, что и остальные.
Lore — открытая система контроля версий от Epic Games, не основанная на Git, с DAGнаправленным ациклическим графом — структурой, где коммиты ссылаются на предков без циклов и оптимизациями для больших бинарных файлов.
Предыстория: 2005 год
В 2005 году шла гонка за версионирование ядра Linux: Bitkeeper нужно было заменить, и Mercurial, Darcs и другие претендовали на эту роль. Затем в гонку вошёл Git и победил; около 2008 года GitHub принёс его массам. Автор называет 2005 год последним большим взрывом, потому что после него многие системы контроля версий приходили и уходили: Accurev, Team Foundation Server от Microsoft, Jazz от IBM, Serena и другие, о которых теперь почти не слышно.
Автор начал с Visual Source Safe в 2000 году, затем работал с Clearcase в Sony в Бельгии, изучил Subversion, CVS и Perforce. В 2005 году основал Plastic SCM, которая была приобретена Unity в 2020 году. Недавно он присоединился к команде Origin, чтобы снова работать над внутренностями контроля версий — теперь не соревнуясь с Git, а стараясь сделать его максимально быстрым.
Почему Git перестал справляться
Распределённая система контроля версий означает, что все экземпляры репозитория идентичны, и в репозитории на сервере нет ничего особенного по сравнению с репозиторием на ноутбуке разработчика. Это создаёт сложности масштабирования и надёжности.
Нет корреляции между расположением объектов в DAG и их размещением в packfile: ключевая эвристика при генерации packfiles — минимизация размера, объекты размещаются случайно, сжимаются и редко хранятся целиком, чаще как дельта поверх другого объекта. Это вызывает случайные обходы гигабайтов данных при каждой операции, что плохо сочетается с сетевой файловой системой, а при сотнях тысяч репозиториев кэширование невозможно.
По сериализации коммитов: коммит в main на Git-форджах требует некоторой сериализации, поэтому существует предел скорости таких коммитов.
Как устроен Origin
Репликация Git-репозиториев в Origin работает не с самим Git, а с packfile-ами: данные хранятся как настоящие Git-репозитории на локальных NVMe-дисках, а реплики поддерживаются в синхронном состоянии.
Консистентность достигается тем, что packfile-ы рассылаются на все хосты одновременно без синхронизации, а затем выполняется трёхфазный коммитпротокол согласования, при котором участники сначала готовятся к фиксации, затем подтверждают её и лишь потом завершают операцию для транзакции ссылокгрупповое изменение ссылок репозитория, которое применяется целиком или не применяется вовсе, которая меньше и быстрее синхронизируется, чем packfile. Git умеет готовить транзакции ссылок: захватывать блокировку, проверять ожидаемое значение и удерживать блокировку до commit или abort. Благодаря этому каждый push полностью синхронизируется по всем репликам, и чтения можно безопасно направлять на любую одну реплику.
Push не подтверждается до записи в WALжурнал предварительной записи, куда операция попадает до её применения, чтобы её можно было восстановить после сбоя на S3: система хранит push как WAL-запись в S3 и никогда не подтверждает push, пока он не будет полностью сохранён. Каждый push хранится отдельным объектом, а packfile пишется на диск и загружается в S3 одновременно. Загрузка WAL-записи сама по себе не публикует push: push становится видимым только после успешной подготовки транзакции ссылок на локальной копии репозитория и записи указателя на WAL-запись в WAL index fileфайл-указатель, который отмечает, какие записи журнала уже применены и доступны для чтения. Это делает все push линейризуемыми.
Проблема NVMe и компактификация
Из-за случайных шаблонов чтения по packfiles хранение обычных Git-репозиториев на NVMe-дисках фактически обязательно для быстродействия базовых операций Git. Современный Git научился обходить это: он поддерживает multi-pack indexesиндексы, позволяющие искать объекты сразу по нескольким упаковкам, а не по одной и incremental geometric compactionпостепенное объединение упаковок по геометрической схеме, при котором мелкие паки сливаются в более крупные. Однако в конечном счёте всё равно приходится делать repackпереупаковку репозитория на диске — очень ресурсоёмкую по CPU операцию, даже при инкрементальном выполнении, и её нужно производить на всех репликах системы.
В SpokesПодход к репликации Git-репозиториев на уровне приложения, который работает не с самим Git, а с packfile-ами, хранит данные как настоящие Git-репозитории на локальных NVMe-дисках и реплицирует данные, поддерживая все копии в синхронном состоянии. стоимость компактификации амортизируется: компактификацию делает только primaryглавный узел, который выполняет запись и компактификацию, тогда как остальные реплики лишь следуют за ним, а результат применяется и к репозиторию на диске, и к WAL. Реплики не делают repack, а просто скачивают уже скомпактированные паки из S3, обменивая пропускную способность на CPU. Чем больше пушей в секунду принимает репозиторий, тем сильнее деградирует производительность чтения, потому что packfiles каждого пуша должны быть скомпактифицированы.
Пропускная способность
Пропускная способность push у кластера зависит от задержки обновления WAL в S3. При использовании S3 Standard кластер выдерживает до 120 push/с, одновременно выполняя компактирование и репликацию скомпактированных данных на все остальные узлы. На высокопроизводительных кластерах с S3 Express One Zoneкласс хранилища S3 с существенно более низкой задержкой операций PUT, где задержка операций PUT существенно ниже, можно принимать более 300 push/с, и узким местом становится скорость компактирования данных Git на диске.
Число реплик может быть любым. В синтетических стресс-тестах проверяли до 100 реплик с линейным масштабированием чтения без падения пропускной способности push.
Как работают другие проекты
GitButler — клиент контроля версий, работающий поверх Git, с бэкендом на Rust и интерфейсами GUI и CLI. Он позволяет вести работу в нескольких ветках одновременно, а не постоянно переключаться между ними, и даёт управление коммитами через перетаскивание или простые CLI-команды. В GitButler rebases всегда завершаются успешно, а коммиты можно помечать как конфликтные и разрешать их в любое время и в любом порядке.
Jujutsu использует Git-репозитории как слой хранения, но хранит закладки и прочую метаданные вне Git. Рабочая копия представлена настоящим коммитом, который автоматически фиксируется и изменяется почти всеми командами. Информация о конфликтах записывается прямо в коммиты, операция при этом завершается успешно, а разрешение можно отложить. При изменении коммита его потомки автоматически перебазируются, даже если есть конфликты.
Lore от Epic Games — полный стек, не основанный на Git, ориентированный на большие монорепозитории и игровую индустрию. Он разделяет с Git лежащий в основе DAG, но добавляет улучшения для работы с большими бинарными файлами и оптимизированную передачу данных, чтобы патчить только изменения и избегать лишних загрузок. Lore выглядит централизованной, но может работать и в отключённом режиме. Для сверхбольших монорепозиториев с миллионами файлов обычная раскладка Git не помогает.
Что это меняет на практике
Привычки «как на GitHub» ослабевают: вместо постоянного переключения веток — работа в нескольких ветках одновременно, вместо ручного rebase -i — управление коммитами перетаскиванием или простыми CLI-командами. Рабочая копия перестаёт быть особым грязным состоянием: в Jujutsu она сама является коммитом, поэтому команды не падают из-за незакоммиченных изменений и не нужен git stash.
Конфликты становятся объектами первого класса: операция завершается успешно, а информация о конфликтах записывается в коммиты, разрешать их можно позже и в любом порядке. Вместо отдельных прерываемых операций появляется единый рабочий процесс разрешения конфликтов, и это позволяет корректно перебазировать merge-коммиты.
Новая парадигма может быть не продуктом, а именно набором принципов: централизованные монорепозитории, версионируемые рабочие пространства, конфликты первого класса. При этом сохраняется совместимость с Git: коммиты выглядят как обычные Git-коммиты, можно работать с любым Git-remote и даже использовать jj и git в одном colocated-репозиториилокальном рабочем пространстве, где команды jj и git можно применять по очереди к одному и тому же репозиторию.
Ограничения и открытые вопросы
Автор прямо признаёт, что не знает, кто победит и на этот раз. Он допускает несколько вариантов исхода: GitHub может адаптироваться, как Microsoft в конечном счёте всегда делает; одна из упомянутых forge может стать основным домом для кода, написанного агентами; либо победителем окажется не продукт, а парадигма — централизованные монорепозитории, версионируемые рабочие пространства, конфликты первого класса.
Автор не берётся предсказать исход, потому что все эти сценарии для него одинаково открыты, и вместо прогноза предлагает вернуться к вопросу позже. Единственное, что он утверждает с уверенностью, — это конец застоя.
