Большой проект трудно поддерживать, когда за один запрос меняются форма, авторизация и структура данных. После ошибки непонятно, какое решение её вызвало и какую часть нужно вернуть.
Я предлагаю выделять изменение с одним результатом и собственной приёмкой. Например: исправить сохранение сообщения после ошибки сети. Изменение тарифа, новая роль пользователя и переработка дизайна идут отдельными задачами.
Карта проекта вместо пересказа всей истории
Сохраните короткое описание: с какого файла запускается проект, где лежат страницы, откуда берутся данные, какие сервисы подключены и как проверить работу. Рядом запишите принятые решения: кто имеет доступ к данным, какие действия измеряются и какие программы нужны для запуска. В PROJECT_STATE.md храните сведения о текущей задаче.
Дайте каждому изменению понятную запись: причина, затронутые части, проверка и способ восстановления. Если нужно изменить структуру базы, например добавить или удалить колонку, запишите это отдельным действием. Такое изменение называется миграцией. Нельзя спрятать удаление колонки под формулировкой «оптимизация».
Промпт: Выполнить ограниченное изменение
Отдельная копия проекта полезна, когда несколько задач меняют одни файлы. Для маленькой правки она может быть лишней. Перед объединением проверьте состав изменений и сохранность чужой работы.
Проверки, которые запускаются сами
CI означает автоматические проверки при обновлении кода. Настройте то, что поможет заметить поломку: сборку, критичный пользовательский путь, работу прав и совместимость интерфейса данных. Тест должен проверять поведение, на котором проект может сломаться.
GitHub Actions позволяет запускать готовые программы проверки. Для чужой программы GitHub рекомендует указывать точный идентификатор её версии, SHA коммита, и сверять его с исходным проектом. Права токена и работа с секретами тоже требуют ограничения. Закреплённая версия не обновится незаметно. Её код всё равно нужно проверить. GitHub: secure use.
Результат CI запишите в журнал проверок. Перед выпуском всё равно нужно проверить целевую конфигурацию и результат в интерфейсе, особенно когда меняются данные или интеграции.
Промпт: Собрать сведения для выпуска
Код, данные и файлы восстанавливаются отдельно
Git хранит историю файлов проекта. Сохранённое состояние называется коммитом. Из него можно вернуть файлы, которые Git отслеживает. Она не возвращает строки базы, удалённые загруженные документы или изменения в кабинете провайдера. Поэтому «откатили коммит» ещё не означает «восстановили приложение».
В учебном примере есть три части: настройки программы в app.json, две вымышленные записи данных и отдельный текстовый документ. Данные сохранены в JSON, текстовом формате с именами полей и их значениями. Сначала сохранены исходный коммит и независимые копии данных и файла. Затем сделано намеренно ошибочное изменение кода и испорчены учебные данные.
Из исходного коммита восстановлен только app.json, после чего создан новый коммит восстановления. История ошибочного изменения сохранилась. Данные и документ возвращены из своих копий. Проверка сравнила контрольные суммы SHA-256. Это цифровые отпечатки содержимого, по которым можно проверить совпадение файлов.
| Проверка опыта | Результат |
|---|---|
| Исходный код сохранён в истории Git | Пройдено |
| Копии данных и файла совпадают с оригиналами | Пройдено |
| Ошибочное изменение имеет отдельный коммит | Пройдено |
| Выбранный файл кода восстановлен байт в байт | Пройдено |
| История сохранена, создан коммит восстановления | Пройдено |
| Несвязанный неотслеживаемый файл сохранён | Пройдено |
| Две синтетические записи восстановлены | Пройдено |
| Содержимое отдельного файла восстановлено | Пройдено |
Команда опыта использует git restore --source <исходный-коммит> -- app.json. Она перезаписывает выбранный файл рабочей копии. В реальном проекте сначала сохраните его незавершённые изменения и убедитесь, что выбрали нужный источник. Это не универсальная команда отката сервера. Git: restore.
Повторить опыт можно из архива «Учебный проект - восстановление»: распакуйте его в отдельную папку и выполните python3 run_demo.py. Нужны Python 3 и Git. Скрипт создаёт внутри своей папки новый учебный каталог, использует синтетическую Git-идентичность только для локальных команд и не отправляет ничего в удалённый репозиторий.
Ожидается passed: 8, total: 8. В results.json сохраняются версии среды и результат. Код скрипта приложен, чтобы можно было увидеть область изменений. Windows-команда с установленным launcher: py -3 run_demo.py; здесь она не проверялась.
Этот опыт использует JSON и обычный файл. Проверка восстановления SQL-базы, объектов облачного Storage и согласованного состояния работающего сервиса остаётся отдельным сценарием.
Промпт: Подготовить восстановление конкретной версии
Аналитика после изменения
Выберите показатель, связанный с результатом задачи. Для формы это отправки, ошибки и получение заявки сервером. Клиентское событие нажатия кнопки не подтверждает запись в базе.
Запишите схему событий: название, момент отправки, свойства, идентификатор и правила удаления дублей. Не добавляйте текст сообщений пользователей в аналитические события без необходимости. На синтетических данных сравните отчёт с контрольной таблицей.
При появлении сбоя сохраните версию, время, наблюдение и относящиеся журналы. Секреты и персональные данные в отчёт не включайте. После исправления повторите тот путь, на котором возникла ошибка, и обновите CHECKS.md фактическим результатом.
