Объедините две кодовые базы: выберите источник правды и аккуратно мигрируйте

Почему две AI‑сгенерированные кодовые базы быстро становятся проблемой

Два AI‑инструмента могут за выходные дать две очень разные версии одного и того же приложения. Возможно, вы начали с v0 ради скорости, потом перезапустили в Replit, когда всё стало запутанным. Или кто‑то из команды попробовал Lovable или Bolt и «починил» пару экранов там. Каждый репозиторий по отдельности может выглядеть правдоподобно, и возникает соблазн держать оба и разобраться позже.

Именно тут всё и начинается. Прототипы быстро расходятся. UI может выглядеть похоже, но логика под ним часто — совсем другая. В одном репозитории роли хранятся в таблице, в другом — в JSON‑объекте. В одном предполагается вход по email, в другом — OAuth. Через неделю у вас уже не просто два репозитория. У вас два набора допущений.

Частые сценарии отказа проявляются быстро:

• Один и тот же баг существует дважды, но с разными симптомами.
• Бизнес‑правила конфликтуют (ценообразование, права доступа, правила статусов), так что «правильность» зависит от того, какой репозиторий запущен.
• Модели данных разъезжаются, миграции становятся рискованными, отчёты ненадёжны.
• Исправления безопасности попадают только в одно место, оставляя другое как ловушку.

Попытки сливать две кодовые базы построчно обычно только усугубляют проблему. В результате вы сшиваете несовместимые паттерны, копируете сломанные потоки аутентификации и подтягиваете небезопасные запросы или утёкшие секреты из более слабого репозитория. Итог — третья кодовая база, которую понять сложнее, чем любую из оригинальных.

Хороший результат прост: одна кодовая база — источник правды, один путь деплоя и одно место для фикса багов. Вы всё ещё можете переиспользовать удачные идеи из другого репозитория, но только через намеренную миграцию фич. Цель не в том, чтобы «объединить всё». Цель — «выбрать одну, которой доверяем, и переносить только то, что можем проверить».

Что означает «источник правды» (и что не означает)

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

Это не значит, что выбранный репозиторий идеален, чист или даже нравится вам больше. Это также не значит, что вы удаляете другой репозиторий в день выбора. Его можно сохранить для сравнений или чтобы понять ожидания пользователей. Разница — в управлении: только один репозиторий движется вперёд.

Прежде чем выбрать, чётко опишите, что покрывает «правда», чтобы потом не было споров. Простые пункты:

• Поведение продукта (фичи и ключевые UX‑пути)
• Модель данных и миграции
• Аутентификация и права доступа
• Настройка деплоя и окружения
• Логирование и обработка ошибок

Затем введите одно правило для всех: победивший репозиторий — единственный доступный для записи. Второй становится только для чтения и остаётся таким.

Также задайте дедлайн для решения. AI‑сгенерированные прототипы быстро расходятся, особенно если два инструмента продолжают генерировать новые файлы. Практичная цель — 24–72 часа: выберите один, зафиксируйте другой и затем мигрируйте осознанно. Если вы не уверены, какой репозиторий безопаснее, быстрый аудит выявит высокие риски в первую очередь, особенно в зонах аутентификации, секретов и запись‑в‑БД.

Быстрое сравнение двух кодовых баз без глубокой экспертизы

При необходимости слить два репозитория не начинайте с дискуссий о том, какой «выглядит лучше». Начните с проверки, какое из них ведёт себя как настоящее ПО под базовой нагрузкой: запускается, собирается, деплоится и падает предсказуемо.

Простой скоринг заставит сравнение быть честным. Оценивайте каждый репозиторий по 0–2 (0 = не проходит, 1 = нестабилен, 2 = надёжен) для:

• Запуска локально из чистой установки (без ручных секретных шагов)
• Сборки и деплоя повторяемым способом
• Наличия хотя бы нескольких полезных тестов (или возможности быстро их добавить)
• Отсутствия хаков (захардкоженные URL, скопированные конфиги, случайные обходы)
• Появления понятных ошибок, на которые можно действовать (не молчалые сбои)

Далее пробегитесь по красным флагам, которые можно заметить без роли специалиста по безопасности: секреты, закоммиченные в репозиторий, «временные» обходы аутентификации, сырые SQL‑запросы, собранные из пользовательского ввода, или API‑маршруты без проверок доступа. Если один репозиторий явно ломает аутентификацию или содержит явные риски инъекций, предполагайте более глубокую проблему.

Посмотрите также на структуру и стройность сборки. Здоровый репозиторий обычно имеет очевидный layout (UI, бэкенд, миграции), переменные окружения в одном месте и один понятный способ запустить и задеплоить. Если логика дублируется в случайных файлах, нейминги непоследовательны или есть несколько конкурирующих файлов конфигурации — потом вы за это заплатите.

Наконец, проверьте удобство сопровождения: сможет ли новый человек за 30 минут найти, где происходит логин, где хранятся данные и где живут основные API‑маршруты? Если нет — баги будут возвращаться после «фиксирования».

Пошагово: выберите победивший репозиторий и заморозьте другой

Держать два репозитория — значит удваивать баги и решения. Самый быстрый путь — выбрать один как источник правды и использовать другой только как донор фич.

Выбирайте основу, которая безопаснее и проще для выпуска, даже если UI в ней выглядит хуже. Безопасность означает меньше неизвестных, меньше костылей и меньше мест, где одно изменение ломает три экрана.

Если затрудняетесь, оцените оба репозитория по нескольким реальным чек‑пойнтам:

• Может ли новый человек запустить его локально без детективной работы?
• Работает ли аутентификация end‑to‑end (регистрация, вход, сброс, выход)?
• Секреты обработаны безопасно (не в коде и не на виду)?
• Согласована ли модель данных (одна ясная схема, минимум хаков)?
• Деплойится ли он без одноразовых ручных правок?

Как только выбрали победителя — заморозьте другой репозиторий. Никаких новых фич, никаких «быстрых фиксов», никакого параллельного ребилда. Сделайте его только для чтения, чтобы он не мог тихо дрейфовать и тянуть команду обратно в split‑brain разработку.

Далее составьте короткий список того, что обязательно сохранить из проигравшего репозитория. Описывайте результаты, а не экраны: «пользователи могут экспортировать счета», «админы могут делать возвраты», «клиенты могут изменить способ оплаты». Это станет вашим бэклогом миграции.

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

• Существующие пользователи должны логиниться тем же email.
• Никаких двойных списаний.
• Только админы могут просматривать данные клиентов.

Пошагово: миграция фич без копирования багов

Самый безопасный подход — скучный: переносите по одному рабочему пользовательскому потоку и доказывайте его корректность, прежде чем брать следующий.

Начните с самой маленькой вертикальной фичи, которую можно полностью выпустить. Выберите поток, затрагивающий UI, бэкенд и данные, но остающийся изолированным (например: регистрация, создание одной сущности, её отображение в списке). Это быстро выявит маршруты, форму API и предположения о базе данных без уводящих в бесконечные edge‑кейсы.

Портируйте поведение, а не код

Считайте старый репозиторий спецификацией, а не исходником для копирования файлов. Прочитайте, что он делает, и реализуйте это поведение чисто в новом репозитории. Копирование файлов — это способ импортировать скрытые глобальные переменные, небезопасные запросы и «работает у меня»‑костыли.

Практический цикл:

• Выпишите ожидаемые входы, выходы и сообщения об ошибках для потока.
• Реализуйте эндпоинты и UI на основе этого поведения.
• Минимизируйте изменения модели данных, пока поток не станет стабильным.
• Добавьте небольшой feature‑флаг (хотя бы конфигурационный), чтобы можно было включать и выключать новый поток.

Когда слайс работает, переходите к следующей фиче тем же способом. Держите миграции маленькими и PR‑ы фокусированными. Перенос двух несвязанных фич одновременно мешает понять, что сломалось.

Проверяйте после каждого шага

После каждой фичи прогоняйте те же быстрые проверки:

• Пройдите поток дважды (новый пользователь и существующий).
• Убедитесь, что данные в базе соответствуют ожиданиям.
• Подтвердите, что в логах сервера нет новых ошибок или предупреждений.
• Проверьте, что можно откатиться (отключить флаг).

Если в одном репозитории есть приглашения команды, не копируйте код приглашений дословно. Воссоздайте поведение приглашения (кто может приглашать, что отправляется, как принимается), а потом убедитесь, что токены не попадают в логи.

Зоны высокого риска: аутентификация и миграции данных

При слиянии двух репозиториев чаще всего ломаются аутентификация и данные. В демо они могут выглядеть «готовыми», но мелкие различия между репозиториями могут заблокировать пользователей, допустить утечку данных или повредить записи.

Аутентификация: проверяйте end‑to‑end

Аудитируйте аутентификацию прежде, чем переносить «приятные» фичи. Не ограничивайтесь проверкой наличия страницы входа. Проверьте полный цикл: вход, хранение сессии, выход и поведение ошибок.

Базовые проверки аутентификации:

• Вход работает с реальными аккаунтами, не только демо‑пользователями.
• Сессии сохраняются после перезагрузки и истекают по расписанию.
• Токены для сброса пароля работают и не могут быть повторно использованы.
• OAuth‑коллбэки соответствуют доменам и путям редиректа.
• Роли и права соответствуют задуманной модели (админ/участник/гость).

Обычная ошибка при миграции: в репозитории A используют cookie‑сессии, а в B — токены в localStorage. Оба варианта отдельно «работают», но их смешивание даёт случайные вылоги и сломанные защиты.

Миграции данных: сначала спланируйте модель, потом переносите

Прежде чем мигрировать фичи, опишите модель данных простым языком: таблицы или коллекции, обязательные поля, связи и где может быть null. Если одна и та же сущность называется по‑разному (userId vs owner_id), считайте это задачей миграции, а не заменой через поиск‑и‑замену.

Планируйте миграции как контролируемый релиз:

• Делайте бэкап, который можно быстро восстановить.
• Репетируйте на staging с реалистичным объёмом данных.
• Определите откат (и что будет, если часть данных уже перенесена).
• Мигрируйте малыми партиями, когда возможно.
• Валидируйте суммарные показатели и выборочно проверяйте критичные записи (пользователи, платежи, права).

Верификация при жёстком таймлайне: тесты, которые действительно нужны

Скорость важна, но пропуск базовых проверок — способ выпустить тот же баг снова. Цель — не идеальное покрытие, а уверенность, что новый источник правды работает для реальных пользователей.

Начните с минимального набора end‑to‑end проверок. Это потоки, которые доказывают, что приложение пригодно к использованию и безопасно для денег:

• Регистрация и онбординг (как у вас на самом деле)
• Вход, выход и сброс пароля
• Основной рабочий поток, за который пользователи платят
• Платежи и возвраты (если есть), включая проваленный платёж
• Одно админ‑действие или настройка, которая меняет данные

Затем добавьте несколько дешёвых автоматических проверок, которые быстро ловят регрессии:

• Линтинг и форматирование
• Проверки типов (если используете TypeScript)
• Небольшое количество модульных тестов там, где логика стабильна

Держите staging близко к продакшену. Используйте те же имена переменных окружения и тот же способ их загрузки, соответствуйте типу БД. Классическая ошибка — «работает на staging», потому что staging использует SQLite, а в проде — Postgres.

Ведите короткий дневник багов: что сломалось, где это поправили и что бы поймало это раньше (тест, правило линтера, отсутствующая переменная окружения). Это поможет не допустить возврата тех же ошибок при следующих миграциях.

Частые ловушки, которые воссоздают ту же кашу

Большинство команд попадает в проблему, когда рассматривает слияние как простое «лучшее из обеих». Если оба репозитория быстро сделаны разными AI‑инструментами, у них часто одни и те же слабые места, просто в разных местах.

Типичные ловушки:

• Один гигантский merge, после которого недели уходит на распутывание конфликтов и дублированной логики.
• Копирование целых файлов для переноса фич и подтягивание небезопасных паттернов (захардкоженные секреты, небезопасный SQL, отсутствующие проверки доступа).
• Одновременные изменения UI и бэкенда, из‑за чего непонятно, что поломало работу.
• Разбежка зависимостей, из‑за которой сборки падают на чистой машине или в CI.
• Отношение к деплою как к последнему шагу, после чего выясняется, что env vars, миграции или хостинг не соответствуют реальности.

Небольшой пример: вы копируете «рабочую» страницу логина из репозитория B в A. Она выглядит нормально, но приносит helper, который логирует токены в консоль и пропускает серверные проверки сессии. Вы поправили экран, но заново ввели дырку в безопасности.

Ограждения, которые помогают двигаться:

• Переносите по одному слайсу фичи и ставьте чек‑поинт перед следующим.
• Реализуйте минимальное поведение в выигравшем репозитории вместо копирования файлов.
• Зафиксируйте версии рантайма и пакетов как можно раньше и проверьте чистую установку.
• Сделайте «dry run» деплоя, как только первая мигрированная фича окажется в репозитории.

Быстрый чек‑лист перед окончательным решением

Прежде чем слить два репозитория в один путь, остановитесь и убедитесь, что вы сможете жить с принятым решением несколько недель. Цель — предсказуемые релизы и меньше сюрпризов.

Сначала сделайте проигравший репозиторий безопасным для хранения без возможности продолжать изменения. Если туда всё ещё можно пушить быстрые правки, у вас снова появится две версии реальности.

Используйте это как пропуск:

• Старый репозиторий заморожен (только для чтения), явно помечен как архив, и вы зафиксировали последний известный рабочий коммит или тег.
• Выбранный репозиторий собирается с нуля на чистой машине по задокументированным шагам (install, env vars, build, run), и эти шаги сработали дважды подряд.
• Деплой повторяем, и вы можете откатиться к предыдущему билду.
• Вход и регистрация работают end‑to‑end для новых и существующих пользователей, включая сброс пароля и истечение сессий.
• Секреты не закоммичены, переменные окружения задокументированы.

Конкретный способ проверить последний пункт: прогоните три ключевых пользовательских пути на staging (например: регистрация, выполнение основной задачи, оплата или экспорт), используя тестовые аккаунты и данные, похожие на продакшен.

Пример: выбор между v0‑сборкой и Replit‑пересборкой

Фаундер получил две версии одного приложения. Первая — v0‑сборка, хорошо выглядит и содержит большинство экранов, но по сути фронтенд‑ориентирована. Вторая — Replit‑ребилд, полный стек, умеет логиниться и сохранять данные, но UI сырой и часть логики продублирована.

Цель не в построчном слиянии. Цель — выбрать один репозиторий как источник правды и переносить только то, что заслуживает места.

Они сравнивают оба репозитория по ряду критериев:

• Где аутентификация работает end‑to‑end (регистрация, вход, выход, истечение сессии)?
• Где модель данных чище (яснее названия, меньше одноразовых полей)?
• Где деплойится без ручных шагов и разбросанных секретов?
• Где меньше «магии» (захардкоженные ID, скрытые админ‑маршруты, случайные таймауты)?

В этом случае выигрывает Replit, потому что там работает аутентификация, и модель данных ближе к бизнес‑требованиям. v0 становится только как дизайн‑референс.

Миграция идёт фича за фичей. Вместо копирования всего UI из v0 команда перестраивает ключевые экраны как компоненты внутри Replit‑репозитория и привязывает их к существующему бэкенду. Начинают с самых ценных потоков: онбординг, основная панель и то действие, которое пользователи выполняют чаще всего.

Перед завершением они валидируют поведение, а не только визуальную часть. Роли и права должны совпадать, формы иметь те же обязательные поля, а состояния ошибок быть понятными (неверный пароль, отсутствующее поле, неудачное сохранение).

Следующие шаги: прийти к одной шиппабельной кодовой базе

Если нужно слить два репозитория, самый быстрый способ прекратить хаос — приостановить фичевую работу и сделать короткий письменный аудит. Вы не оцениваете стиль кода. Вы выясняете, что безопасно шиппить и что сломает вас позже.

Выпишите, что вы знаете сегодня:

• Самые болезненные пользовательские баги (что, где, как воспроизвести)
• Главные риски (безопасность, потеря данных, неожиданные расходы)
• Фичи, которые нужно сохранить (и что может подождать)
• Что уже работает в проде (даже если уродливо)
• Что блокирует деплой (env vars, шаги сборки, отсутствующие миграции)

Затем примите одно решение: чинить и мигрировать или переписать с нуля по тем же требованиям. Если один репозиторий имеет стабильную модель данных и предсказуемый деплой, он часто выигрывает, даже если UI отстаёт. Если оба репозитория ненадёжны, чистый ребилд может оказаться дешевле, чем двигать вперёд два набора проблем.

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

Если вы унаследовали AI‑сгенерированные прототипы и хотите одну production‑готовую кодовую базу, FixMyMess (fixmymess.ai) как раз решает такие задачи. Они диагностируют оба репозитория, ремонтируют сломанную логику, укрепляют безопасность, рефакторят запутанную архитектуру и готовят приложение к деплою. Если вы не уверены, какой репозиторий должен победить, их бесплатный аудит кода даст ясный, спокойный план до того, как вы примете решение.