Сброс проекта в чистое состояние для практики

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

Чистое состояние решает три задачи.

1. Повторяемость — каждое упражнение начинается с одинакового набора файлов и одинаковой базы, поэтому результат зависит только от ваших действий.
2. Предсказуемость — агент работает с известной структурой проекта, а не с «тем, что вчера кто-то изменил».
3. Безопасность — сломанный эксперимент не тянется за вами: один сброс — и проект снова в порядке.

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

1. Код на известном коммите — рабочая копия совпадает с последним закоммиченным состоянием, лишних изменений нет.
2. База в начальном виде — таблицы созданы миграциями, пробных и мусорных данных нет.
3. Зависимости установлены — папка node_modules на месте, проект запускается.
4. Временные файлы удалены — логи, кэш и прочий мусор не мешают работе.

Важно понимать: чистое состояние — это не «пустой проект», а «известное состояние проекта». База с таблицей users — нормальное чистое состояние, если она создана миграциями. Главное, чтобы состояние было определённым и воспроизводимым, а не «ну, вроде всё очистилось».

Первый слой грязи — изменения в файлах. Их убирает git. Начнём с проверки, что вообще изменилось с последнего коммита.

git status

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

Возврат к последнему коммиту

Команда git reset --hard приводит отслеживаемые файлы к состоянию коммита, на который указывает HEAD — «голова» ветки, то есть последний сохранённый коммит.

git reset --hard HEAD

>После этой команды изменённые файлы вернутся к виду последнего коммита.

Удаление незакоммиченных файлов

git reset --hard убирает изменения в отслеживаемых файлах, но не трогает новые файлы, которые git ещё не знает. Такие файлы — результаты пробных запусков, черновики, случайно созданные скрипты — удаляет команда git clean.

git clean -fd

Флаги означают: -f — применить удаление (без него команда только показывает, что удалила бы), -d — удалять и непустые папки. Вместе с git reset --hard эта команда гарантирует, что рабочая копия точно совпадает с последним коммитом.

Второй слой грязи — данные. За время упражнений в базе появляются пробные записи: тестовые пользователи, заказы, результаты экспериментов. Для учебного проекта правильный способ очистить базу — удалить файл базы и создать структуру заново миграциями.

rm data.db
npm run migrate:up

Первая команда удаляет файл базы вместе со всеми данными, вторая — пересоздаёт структуру из миграций: таблицу schema_migrations и таблицу users. Результат — база в точно таком же виде, как после первого запуска миграций.

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

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

{
  "scripts": {
    "reset": "git reset --hard HEAD && git clean -fd && rm -f data.db && npm run migrate:up"
  }
}

Теперь полный возврат проекта в чистое состояние — одна команда.

npm run reset

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

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

Сброс — это шаг, а у шага есть критерий приёмки. Чистое состояние проверяется тремя проверками.

1. git status — пустой вывод, рабочая копия совпадает с последним коммитом.
2. .tables — в базе только schema_migrations и users, без мусорных таблиц и пробных записей.
3. npm test — проект запускается, проверки проходят, сброс ничего не сломал.

Команда для проверки базы:.

sqlite3 data.db ".tables"

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

git add .
git commit -m "Шаг: добавлен скрипт полного сброса npm run reset"

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

Второе: агент выполняет сброс, а вы проверяете результат по критерию.

1. Проект накопил изменения после упражнений.
2. Выполни сброс: команда npm run reset.
3. Критерий приёмки: git status пустой, sqlite3 data.db ".tables" показывает только schema_migrations и users, npm test проходит.

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

1. Сброс без проверки git status — потеряна незакоммиченная работа.
2. Забыли удалить базу — пробные данные переживают сброс кода.
3. Применение git reset --hard к нужным изменениям без предварительного коммита.
4. Нет скрипта сброса — каждая очистка вручную, что-то обязательно пропускается.
5. Файл базы закоммичен в репозиторий — чистое состояние недостижимо.
6. Отсутствие проверки после сброса: «вроде очистилось» вместо git status и .tables.

Самая дорогая ошибка — потеря незакоммиченной работы. git reset --hard и git clean не спрашивают разрешения и не кладут файлы в корзину: удалённое исчезает навсегда. Единственная страховка — дисциплина: посмотреть git status, нужное закоммитить и только потом сбрасывать.

Чистое состояние — это известное состояние: код на последнем коммите, база, пересозданная миграциями, и скрипт, который приводит проект к этому виду одной командой. Сброс возвращает проекту предсказуемость и делает практику многократной и безопасной.

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

1. Чистое состояние — известное, воспроизводимое состояние проекта, готовое к новому упражнению.
2. Рабочая копия — текущее состояние файлов на диске.
3. Коммит — зафиксированная точка в истории изменений git.
4. HEAD — указатель на последний коммит текущей ветки.
5. git status — команда, показывающая изменения в рабочей копии.
6. git reset —hard — команда возврата файлов к состоянию указанного коммита.
7. git clean -fd — команда удаления новых, не отслеживаемых файлов и папок.
8. Незакоммиченные изменения — правки, которые не сохранены в истории git.
9. .gitignore — файл со списком путей, которые git не отслеживает.
10. База данных — хранилище данных проекта, в курсе — файл data.db.
11. Миграция — файл с изменением структуры базы, оформленный как шаг истории.
12. schema_migrations — служебная таблица со списком применённых миграций.
13. npm run reset — скрипт полного сброса проекта в чистое состояние.
14. Критерий приёмки — условие, по которому задача считается выполненной.
15. node_modules — папка установленных зависимостей проекта.
16. Продакшен — рабочая среда, в которой проект используется реальными пользователями.
17. Recorder — инструмент записи запросов между агентом и моделью (тема следующего урока).