Oak

Oak - это система контроля версий, построенная на предпосылке, что структура Git'а не подходит агентам. Базовые концепции сохранены - репозитории, ветки, коммиты, push и pull, - однако хранилище адресно по содержимому и использует content-defined chunking, рабочие деревья представляют собой ленивые монтирования вместо полных клонов, а промежуточные коммиты вообще не содержат сообщений. Суть предложения для оператора агентов в том, что менять модель, агента или редактор не нужно; достаточно сказать агенту вызывать oak там, где он раньше запускал git.

Четыре претензии

Каждое инженерное решение отвечает на конкретное неудобство, о котором говорит сайт. Клонирование большого репозитория ради чтения одного файла отнимает минуты времени и токены на наблюдение за индикатором прогресса, поэтому oak mount скачивает манифест и наполняет содержимое файлов только при первом чтении. Параллельные задачи в Git'е делят одну папку .git, которую любой повреждённый индекс может заблокировать целиком, поэтому каждое монтирование Oak получает собственное рабочее дерево на отдельной ветке, и удаление одного из них не трогает остальные. Git требует текст к каждому коммиту, из-за чего агенты генерируют "wip" и "fix", которые никто не читает, поэтому промежуточные чекпоинты Oak сообщений не содержат, а описание ветки становится единственной строкой, попадающей в squash-коммит в main. Из-за больших бинарников Git приходится связывать с LFS с её отдельными квотами и привычкой заново загружать файл целиком ради изменения одного тензора, поэтому Oak нативно делит файлы на чанки, дедуплицирует их и передаёт только изменившиеся фрагменты.

Модель веток логично продолжает тему с описаниями. Команда oak init помещает вас в feature-ветку с родителем в main, а сама ветка main существует только на сервере, поэтому локальная основная ветка не может рассинхронизироваться. Слияние представляет собой squash на стороне сервера. Прямые push'и в main отклоняются, за исключением самого первого push'а в пустой репозиторий - это прямой барьер против некорректно настроенного агента, который мог бы сделать fast-forward туда, куда не следует.

Монтирования живут внутри oak space - единого рабочего пространства для всей организации, а не для одного репозитория. Каждая задача - это поддиректория внутри space; внутри неё монтируются те репозитории, которые нужны задаче, поэтому изменение, затрагивающее три репозитория, держит три свои ветки бок о бок.

$ oak space new acme
$ oak mount acme/app ./fix-auth
$ oak switch -c feat/oauth
$ oak desc "Replace REST auth with OAuth + PKCE"
$ oak merge          # squashed onto main, description becomes the message

Цифры и их источник

Главное заявление разработчиков - снижение p50-задержки вплоть до 95% по сравнению с Git'ом: снятие снапшота для 50 тысяч файлов занимает 1.4 с вместо 29.7 с. Это цифры от авторов инструмента, однако бенчмарки открыты на oak.space/oak/benchmarks, и сайт предлагает запустить их самостоятельно, что встречается не так часто. Честная часть этой же страницы показывает, где Git всё ещё впереди: холодная инициализация репозитория и запуск процесса, где Oak несёт фиксированные накладные расходы, которые пока не удалось убрать. Расчёт строится на том, что эти расходы амортизируются за долгую сессию агента с постоянными снапшотами и проверками статуса.

Ограничения

CLI работает только на macOS (Apple Silicon) и Linux (x86_64), поскольку для ленивого монтирования требуются FSKit на macOS и FUSE на Linux. Поддержка Linux ARM64 и Windows находится в планах. Здесь нет трекера задач, код-ревью, CI и всего багажа инструментов, наработанного вокруг GitHub за десятилетие, - сайт прямо признаёт это и предлагает использовать собственные решения.

Команда oak export ./dest воспроизводит историю ветки в стандартный репозиторий Git с сохранением автора, email и таймстемпов, а read-only эндпоинт Git Smart-HTTP позволяет забрать текущий main через обычный git clone. Этот путь отхода здесь особенно важен, поскольку нахождение main только на сервере делает использование хостинга обязательным. Oak заявляет, что не делает вызовов к LLM от вашего имени и не обучает модели на коде пользователей; запускаемый рядом агент остаётся отдельной интеграцией со своими правилами безопасности.

Ещё одна деталь, заслуживающая внимания перед внедрением: Oak предлагает вставить в CLAUDE.md или AGENTS.md инструкцию для агента, требующую отправлять oak feedback -m "..." --json каждый раз при возникновении проблем. Это остроумный способ получать отчёты об ошибках от той стороны, которая непосредственно сталкивается с задержками, но одновременно и постоянное указание вашему агенту отправлять текст разработчикам инструмента. Стоит проверить состав передаваемых данных перед включением.

Проект отслеживается в watchlist: лицензия не указана, размещённый у авторов сервер находится на критическом пути, поддерживаются только две платформы, а сам проект ещё молод и конкурирует с самым укоренившимся инструментом в индустрии.

Связанные страницы: jujutsu идёт другим путём, сохраняя Git в качестве бэкенда и меняя модель рабочего процесса; billjings-git-not-fine разбирает примитивы Git'а, ломающиеся при асинхронной работе и stacked-изменениях. О том, что агенты делают с системой контроля версий на практике, см. claude-code и log-is-the-agent, делающий схожую ставку на дешёвое ветвление с другой стороны.

Исходный код доступен на oak.space/oak/oak; установка через curl -fsSL oak.space/install | sh. Лицензия на сайте не указана.