For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /ru/docs/web/updating-the-kit.md (or send Accept: text/markdown).
Обновляйте свою копию, когда комплект улучшается
Переносите улучшения из исходного репозитория в свою копию: зафиксируйте точку старта, получите новую ревизию, слейте её в отдельной ветке и проверьте перед развёртыванием.
1. Зафиксируйте, с чего вы начали
Относитесь к обновлению как к маленькому проекту, а не как к вставке: вы сравниваете имеющуюся у вас ревизию комплекта с более новой, переносите изменения и тестируете в ветке до развёртывания. Это работает независимо от того, является ли ваш проект форком репозитория комплекта — копии, которую GitHub держит связанной с источником, — или кодом, который вы скопировали в собственное приложение.
Прежде всего остального запишите в своём проекте заметку с тремя вещами: коммит комплекта, с которого вы начали — SHA, короткий код Git, идентифицирующий одну точную версию, — полученный вами репозиторий (supastack-web, supastack-mobile, supastack-desktop или монорепозиторий All Platforms) и изменения, которые вы уже внесли сами.
У репозиториев комплекта и монорепозитория разные истории, поэтому никогда не сливайте ветку из одного в форк другого. Если вы не записали стартовый SHA, найдите ближайшую общую версию с помощью git merge-base в форке или определите последние скопированные файлы и тесты при выборочном переносе — а когда точная база неизвестна, просматривайте более широкий diff.
2. Получите и слейте новую ревизию
Выполните команды ниже в терминале внутри папки проекта, сохранив и закоммитив свою работу — чистое рабочее дерево, чтобы ничего недоделанного не смешалось в слияние. Слова в угловых скобках — это шаблоны «замени меня»: подставьте собственные значения вместо всего <thing>. Показанный адрес GitHub — заглушка; используйте адрес репозитория, который вы форкнули.
Что делают строки: git remote add сообщает вашей копии второй адрес с именем kit-upstream — репозиторий комплекта, — а git fetch загружает его новейшее состояние, не трогая ваши файлы. git switch -c создаёт отдельную ветку обновления, чтобы ваша основная ветка оставалась нетронутой, пока вы проверяете. git log перечисляет коммиты, которые вы собираетесь принять, а git diff --stat суммирует, какие файлы изменились; читайте полный diff для используемых вами модулей, а не только заголовки коммитов. git merge приносит новый код в ветку обновления.
Если Git сообщает, что удалённый репозиторий kit-upstream уже существует, пропустите строку remote add и продолжите с git fetch. <previous-kit-sha> — это стартовый SHA, который вы записали на шаге 1.
# Upstream is the platform repository you forked — substitute its real URL
# (supastack-web shown; use supastack-mobile or supastack-desktop as fits).
git remote add kit-upstream https://github.com/<org>/supastack-web.git
git fetch kit-upstream
git switch -c upgrade/kit-update
git log --oneline <previous-kit-sha>..kit-upstream/main
git diff --stat <previous-kit-sha>..kit-upstream/main
git merge kit-upstream/main3. Разрешите конфликты, не теряя свою работу
Конфликт означает, что обе стороны изменили одни и те же строки: комплект пошёл дальше, а вы настроили то же место. Git приостанавливает слияние и помечает файл — он просит вас выбрать, а не сообщает о поломке.
Откройте каждый помеченный файл в редакторе и решайте построчно: оставляйте собственный текст, имена и настройки вашего продукта и берите исправления и структурные изменения комплекта. Никогда не разрешайте конфликт заменой настроенного вами файла на всю новую версию комплекта — это стирает вашу работу. Разрешайте внутри ветки обновления и запускайте тесты для каждой разрешённой области, прежде чем продолжить.
Если слияние пошло не так, git merge --abort возвращает ветку в состояние до слияния. Ничто в этом процессе не меняет вашу основную ветку или развёртывание, пока вы сами не сольёте ветку обновления.
4. Обновляйте данные и развёртывайте в правильном порядке
Новые ревизии комплекта могут менять базу данных. Прочитайте новые файлы в packages/db/drizzle/ — папке миграций — и создайте резервную копию производственных данных перед применением миграций; сначала протестируйте их на одноразовой копии. Развёртывайте совместимые изменения схемы до кода, который в них нуждается: если миграция удаляет или преобразует данные, откат одного кода приложения не сможет восстановить старую схему.
Сравните новый .env.example со своими настройками и добавьте новые обязательные значения в панели управления хостинга. Файлы .env несут секреты и никогда не коммитятся в Git — вы воссоздаёте их вручную на каждой машине и развёртывании, и они не попадают в значения NEXT_PUBLIC_ и EXPO_PUBLIC_.
Перед развёртыванием запустите собственные проверочные шлюзы комплекта. В монорепозитории All Platforms corepack pnpm check:local запускает lint, проверку типов, модульные тесты и проверку формата без платных учётных данных; corepack pnpm verify:local добавляет производственную сборку и браузерные наборы тестов. В форке одной поверхности запустите собственные тестовые и сборочные команды этого репозитория. Затем сделайте пробный прогон на staging: войдите, попробуйте второе рабочее пространство и пройдите основной пользовательский сценарий вашего продукта.
Когда всё проходит, запишите принятый целевой SHA и разрешённые вами конфликты — эта заметка станет стартовой базой для следующего обновления.
corepack pnpm check:local
# fuller gate: adds the production build and browser suites
corepack pnpm verify:local5. Если вы копировали части вместо форка
Выборочный перенос — копирование модулей комплекта в существующее приложение — не имеет общей истории Git с комплектом, поэтому git merge не поможет. Вместо этого сравните старый SHA источника с целевым SHA источника и переносите только те изменения, которые затрагивают перенесённую вами часть.
Просматривайте публичные типы модуля, схему персистентности и миграции, серверный вызов, конфигурацию, тесты и документы как единое целое — изменение внутри пакета может потребовать соответствующего изменения маршрута или окружения в другом месте, а копирование одного помощника может оставить остальное на устаревшем контракте. Ведите короткую заметку об адаптации — какие файлы комплекта вы взяли, какие пропустили, что изменили, — чтобы следующее обновление могло повторить ваш выбор.
Если обновление что-то сломало в вашей рабочей копии, пройдите руководство по устранению неполадок, прежде чем отменять собственные изменения.