Мерж-конфликты надоели всем. Брэм Коэн предлагает их отменить
Если вы хоть раз видели эти строки в терминале — <<<<<<< HEAD, =======, >>>>>>> feature-branch — и чувствовали, как внутри что-то сжимается, вы не одиноки. Merge-конфликты в Git — это одна из тех вещей, к которым все привыкли, но которые никто не любит. Мы тратим часы, чтобы разобраться, кто что поменял, в каком порядке, и какой вариант оставить. И самое обидное — чем больше людей работает над проектом, тем хуже становится ситуация.
22 марта 2026 года Брэм Коэн — человек, создавший протокол BitTorrent и фактически изменивший способ передачи данных в интернете — представил Manyana: proof of concept системы контроля версий, построенной на принципиально другом фундаменте. Не на трёхстороннем мерже, не на эвристиках, а на CRDT — математической структуре данных, в которой конфликты слияния невозможны по определению. И у этого подхода серьёзные последствия для всей индустрии разработки.
Что не так с Git (на самом деле)
Давайте честно: Git — великий инструмент. Он решил кучу проблем распределённой разработки, дал нам ветвление, которое не стоит ничего, и стал стандартом де-факто. Но у него есть архитектурный изъян, который с годами становится всё болезненнее.
Git использует трёхсторонний мерж (three-way merge). Принцип такой: берём общего предка двух веток, сравниваем с каждой из них и пытаемся автоматически совместить изменения. Если обе ветки трогали одни и те же строки — получаем конфликт, который человек должен разрешить руками.
Проблема в том, что Git показывает конфликт как два непрозрачных блока текста — «left» и «right». Вот классический пример из поста Коэна. Два разработчика форкнули файл с функцией. Первый удалил всю функцию. Второй добавил одну строку в её середину. Git выдаст что-то вроде:
<<<<<<< left
=======
def calculate(x):
a = x * 2
logger.debug(f"a={a}")
b = a + 1
return b
>>>>>>> right
Два куска. Слева пусто, справа функция целиком. И сиди разбирайся: кто удалил? кто добавил? что из этого оставить? А теперь представьте, что таких конфликтов в pull request — двадцать. В эпоху AI-агентов, которые рефакторят тысячи строк за один промпт, — это уже не неудобство, а системная проблема.
CRDT: данные, которые не умеют конфликтовать
Ключевая идея Manyana — использование CRDT (Conflict-Free Replicated Data Types, бесконфликтных реплицируемых типов данных). Эта концепция пришла из мира распределённых систем и была формально описана в 2011 году группой исследователей во главе с Марком Шапиро.
Суть CRDT можно объяснить на простой аналогии. Представьте, что у вас есть счётчик «лайков» на посте, и десять серверов по всему миру одновременно принимают нажатия. Каждый сервер увеличивает свою копию. Когда серверы синхронизируются — неважно, в каком порядке, — результат всегда одинаковый. Это и есть CRDT: структура данных, в которой слияние любых реплик всегда успешно и всегда даёт один и тот же результат.
CRDT уже давно используются в продакшене, и в довольно неожиданных местах:
🎮 League of Legends — внутриигровой чат на базе Riak CRDT обслуживает 7.5 миллионов одновременных пользователей и 11 000 сообщений в секунду.
📱 Apple Notes — синхронизация заметок между устройствами работает на CRDT, что позволяет редактировать офлайн и потом безболезненно слить изменения.
💬 Facebook — использует CRDT в нескольких внутренних системах, включая Apollo (база данных для low-latency операций) и FlightTracker.
🛰️ TomTom — синхронизация навигационных данных между устройствами пользователя.
Но до сих пор никто не довёл применение CRDT в контроле версий до убедительной демонстрации. Были отдельные исследования (Automerge Мартина Клеппмана, эксперименты Ink & Switch), но камнем преткновения оставался UX: если мерж никогда не «ломается», то как показать разработчику, что что-то всё-таки требует его внимания?
Как устроена Manyana
Коэн нашёл элегантное решение этой UX-проблемы. Manyana — это 470 строк на Python, которые работают с отдельными файлами. Не полноценная VCS, а proof of concept, но с продуманной архитектурой.
Вот ключевые принципы:
⚙️ Weave-структура вместо DAG. Состояние файла хранится как «weave» — единая структура, содержащая каждую строку, которая когда-либо существовала в файле, с метаданными о том, когда она была добавлена и удалена. Для слияния не нужно искать общего предка или обходить граф коммитов — две версии файла подаются на вход, одна выходит, и результат всегда корректен.
⚙️ Конфликты — информативные, не блокирующие. Мерж всегда проходит. Но если параллельные правки произошли «слишком близко» друг к другу в структуре файла, система помечает их как конфликт для ревью. При этом каждая секция конфликта объясняет, что именно произошло и кто это сделал. Тот же пример с удалённой функцией в Manyana выглядит так:
<<<<<<< begin deleted left
def calculate(x):
a = x * 2
======= begin added right
logger.debug(f"a={a}")
======= begin deleted left
b = a + 1
return b
>>>>>>> end conflict
Разница колоссальная. Вы сразу видите: left удалил функцию, right добавил строку в середину. Не два анонимных блоба, а структурированная история изменений.
⚙️ Порядок строк — постоянный. Когда две ветки вставляют код в одну точку, CRDT определяет порядок, и он фиксируется навсегда. Это предотвращает ситуацию, когда один разработчик при разрешении конфликта поставил блок A перед B, а другой — B перед A, и потом при мерже их результатов получается каша.
⚙️ Коммутативные мерджи. merge(A, B) всегда даёт тот же результат, что и merge(B, A). Более того — можно мержить произвольное количество веток в произвольном порядке, и результат будет одинаковым. Для распределённых команд это означает, что не нужен «каноничный» порядок слияния.
Rebase без уничтожения истории
Отдельно Коэн описывает подход к rebase, и это, пожалуй, самая провокационная часть проекта.
В Git rebase — это переписывание истории. Ваши коммиты «переигрываются» поверх нового состояния main, создавая фиктивную линейную историю. Это удобно для чтения, но создаёт проблему: оригинальная история уничтожается. А при агрессивном ребейзе возникают топологии мержей без единого общего предка — и именно тут Git начинает ломаться по-настоящему.
В системе на CRDT можно получить тот же эффект — последовательное воспроизведение коммитов на новой базе — но с сохранением полной истории. Для этого достаточно добавить аннотацию «primary ancestor» в граф коммитов. CRDT-структуре не нужен общий предок для корректного мержа — вся история уже вшита в weave.
Контекст: почему именно сейчас
У того, что Коэн — да и не только он — обращает внимание на эту тему именно сейчас, есть вполне конкретная причина. И причина эта — AI-агенты, пишущие код.
Комментатор под постом Коэна (Justin D Kruger) точно подметил ключевой сдвиг: в эпоху кодинга с AI WIP-коммиты стали содержать на порядки больше изменённых строк. AI-агент может по одному промпту переписать проект с React на Svelte. Коммит-месседжи не отражают реального содержания. Размер коммитов вышел за рамки того, что Git был спроектирован обрабатывать комфортно.
Добавьте к этому, что в крупных проектах одновременно могут работать несколько AI-агентов плюс люди, и масштаб проблемы становится очевидным. Системе контроля версий нужно уметь мержить десятки параллельных потоков изменений — и делать это предсказуемо, без ручного разбора тысяч конфликтов.
CRDT, с их математической гарантией корректного слияния, оказываются идеальным фундаментом для этого нового мира.
Есть ли у этого шансы?
Здесь стоит быть честным. Manyana — это 470 строк Python и работа с отдельными файлами. Cherry-pick и локальный undo не реализованы. До полноценной замены Git — как до Луны пешком. Git опирается на колоссальную экосистему: GitHub, GitLab, CI/CD-пайплайны, IDE-интеграции, линтеры, код-ревью, миллионы часов обучающего контента. Заменить это нельзя одним элегантным proof of concept.
Но есть несколько аргументов в пользу того, что Коэн на правильном пути.
Во-первых, у идеи серьёзная теоретическая база. Исследователь Мартин Клеппман (автор книги «Designing Data-Intensive Applications» и проекта Automerge) уже несколько лет работает на стыке CRDT и контроля версий. GitHub экспериментировал с CRDT в проекте Eon для синхронизации изменений на уровне отдельных нажатий клавиш. Ink & Switch строит целую экосистему «local-first» приложений на базе CRDT. Manyana — это не голос в пустыне, а ещё один кирпичик в уже формирующемся движении.
Во-вторых, автор — Брэм Коэн. Человек, который в 2001 году придумал BitTorrent и изменил то, как человечество обменивается файлами. А ещё до этого он писал инструменты мержа для систем контроля версий — тема для него не новая. В 2023 году он опубликовал подробный разбор «The State of Merging Technology», в котором уже тогда двигался в сторону CRDT. Manyana — результат нескольких лет размышлений.
В-третьих, код выложен в public domain. Это не стартап с закрытым кодом и инвесторскими амбициями — это приглашение к сотрудничеству. Саймон Уиллисон уже скормил эти 470 строк Claude и построил интерактивный визуализатор мержей. На форумах Pijul (ещё одна альтернативная VCS) пошло обсуждение пересечений с их подходом.
Мой взгляд: Git — новый SVN
Знаете, в начале 2000-х SVN казался вершиной эволюции контроля версий. Центральный сервер, линейная история, всё понятно и предсказуемо. А потом пришёл Git и перевернул всё вверх ногами. Распределённость, дешёвые ветки, офлайн-работа — поначалу это казалось избыточным. «Зачем мне локальные ветки?» — спрашивали люди. Прошло пять лет, и вернуться к SVN стало немыслимо.
Мне кажется, мы стоим на пороге аналогичного перехода. Git — это SVN эпохи AI. Он был спроектирован для мира, где люди пишут код руками, коммиты небольшие и осмысленные, а параллельные ветки — это обычно 2–3 фичи одновременно. Мир, в котором агенты генерируют тысячи строк за промпт, а десять разработчиков и три AI-бота одновременно пушат в один репозиторий, — этот мир требует другого фундамента.
CRDT — это именно такой фундамент. Математически безупречное слияние, детерминированный результат, порядок операций не имеет значения. Manyana пока что — набросок на салфетке. Но набросок, за которым стоит правильная идея и правильный человек.
Полноценная система на основе этих идей вряд ли появится завтра (хотя Коэн наверняка оценил бы иронию — «manyana» по-испански означает «завтра»). Но через 3–5 лет? Я бы не удивился, если CRDT-based VCS станут мейнстримом — хотя бы для определённых сценариев. Особенно для распределённых команд с AI-агентами. Особенно для real-time коллаборации. Особенно для всех, кто устал разбирать merge-конфликты в пятницу вечером.
Источники
⭐ Оригинальный пост Брэма Коэна: https://bramcohen.com/p/manyana
⭐ Подробная статья на Telegra.ph: https://telegra.ph/CRDT-konflikty-i-budushchee-gde-Git--ehto-uzhe-ne-korol-kak-pereizobretayut-kontrol-versij-03-22
⭐ Репозиторий Manyana на GitHub: https://github.com/bramcohen/manyana
⭐ Визуализатор мержей от Саймона Уиллисона: https://simonwillison.net/2026/Mar/22/manyana/
⭐ «The State of Merging Technology» (Bram Cohen, 2023): https://bramcohen.com/p/the-state-of-merging-technology
⭐ Automerge — CRDT для контроля версий (Martin Kleppmann): https://martin.kleppmann.com/2022/03/28/rainbowfs-workshop.html
⭐ Обсуждение на Hacker News: https://news.ycombinator.com/item?id=47478401