> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # Обновляйте свою копию, когда комплект улучшается Переносите улучшения из исходного репозитория в свою копию: зафиксируйте точку старта, получите новую ревизию, слейте её в отдельной ветке и проверьте перед развёртыванием. ## 1. Зафиксируйте, с чего вы начали Относитесь к обновлению как к маленькому проекту, а не как к вставке: вы сравниваете имеющуюся у вас ревизию комплекта с более новой, переносите изменения и тестируете в ветке до развёртывания. Это работает независимо от того, является ли ваш проект форком репозитория комплекта — копии, которую GitHub держит связанной с источником, — или кодом, который вы скопировали в собственное приложение. Прежде всего остального запишите в своём проекте заметку с тремя вещами: коммит комплекта, с которого вы начали — SHA, короткий код Git, идентифицирующий одну точную версию, — полученный вами репозиторий (supastack-web, supastack-mobile, supastack-desktop или монорепозиторий All Platforms) и изменения, которые вы уже внесли сами. У репозиториев комплекта и монорепозитория разные истории, поэтому никогда не сливайте ветку из одного в форк другого. Если вы не записали стартовый SHA, найдите ближайшую общую версию с помощью git merge-base в форке или определите последние скопированные файлы и тесты при выборочном переносе — а когда точная база неизвестна, просматривайте более широкий diff. ## 2. Получите и слейте новую ревизию Выполните команды ниже в терминале внутри папки проекта, сохранив и закоммитив свою работу — чистое рабочее дерево, чтобы ничего недоделанного не смешалось в слияние. Слова в угловых скобках — это шаблоны «замени меня»: подставьте собственные значения вместо всего . Показанный адрес 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. — это стартовый 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//supastack-web.git git fetch kit-upstream git switch -c upgrade/kit-update git log --oneline ..kit-upstream/main git diff --stat ..kit-upstream/main git merge kit-upstream/main ``` ## 3. Разрешите конфликты, не теряя свою работу Конфликт означает, что обе стороны изменили одни и те же строки: комплект пошёл дальше, а вы настроили то же место. 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:local ``` ## 5. Если вы копировали части вместо форка Выборочный перенос — копирование модулей комплекта в существующее приложение — не имеет общей истории Git с комплектом, поэтому git merge не поможет. Вместо этого сравните старый SHA источника с целевым SHA источника и переносите только те изменения, которые затрагивают перенесённую вами часть. Просматривайте публичные типы модуля, схему персистентности и миграции, серверный вызов, конфигурацию, тесты и документы как единое целое — изменение внутри пакета может потребовать соответствующего изменения маршрута или окружения в другом месте, а копирование одного помощника может оставить остальное на устаревшем контракте. Ведите короткую заметку об адаптации — какие файлы комплекта вы взяли, какие пропустили, что изменили, — чтобы следующее обновление могло повторить ваш выбор. Если обновление что-то сломало в вашей рабочей копии, пройдите руководство по устранению неполадок, прежде чем отменять собственные изменения. [Исправьте проблему после обновления](https://supastack.dev/ru/docs/web/troubleshooting.md) ## Вперёд [Обзор модулей](https://supastack.dev/ru/docs/modules.md)