Git-процесс WordPress MVP: маленькие изменения, review и откат

Разработка MVP с AI-агентом удобнее, когда каждое изменение можно прочитать, проверить и отменить. Git сохраняет историю исходников, но сам по себе не делает резервную копию базы WordPress и не гарантирует безопасное развёртывание.

1. Определите, что находится в репозитории

Обычно в Git хранят код собственных плагинов, темы, конфигурацию сборки, тесты и документацию. Не добавляйте реальную базу данных, .env с ключами, приватные файлы, пользовательские медиа и служебные каталоги. Для WordPress-контента и настроек отдельно потребуется стратегия миграций и резервного копирования.

2. Декомпозируйте задачу

Вместо «сделай личный кабинет» задайте один проверяемый результат: «добавь список проектов для текущего пользователя без доступа к чужим данным». Приложите ожидаемое поведение, роли, ограничения доступа и критерии готовности. Предыдущие UX-SPEC и User Flow снижают количество догадок.

3. Работайте через ветку

git status
git switch -c feature/project-list
git diff --check
git diff
git add path/to/changed-file.php
git commit -m "Add project list screen"

Перед git add внимательно проверьте список файлов; массовое добавление может случайно включить секреты. Проверяйте git diff глазами, особенно изменения прав доступа, SQL и операции удаления. Команда git diff --check проверяет пробелы и подобные ошибки, а не безопасность программы.

4. Review и тестирование

Попросите агента сообщить: изменённые файлы, причины решений, риски, способы проверки и ограничения. Проверьте PHP-синтаксис, автоматические тесты, если они есть, и основные UX-сценарии вручную. Для командной работы используйте pull request и защиту основной ветки, если это подходит процессу — GitHub Docs.

Если тесты не запускались, пишите «не запускались», а не «прошли».

5. Продумайте откат заранее

Перед слиянием отметьте, какие изменения касаются базы и что будет, если релиз придётся отменить. Откат Git-коммита не отменяет произведённые миграции данных. Для обновлений схемы и интеграций должен быть отдельный план безопасного восстановления.

Шаблон записи по задаче

## CHANGE-LOG-ENTRY
- Задача и измеримый результат:
- Ветка / коммит / PR:
- Изменённые файлы:
- Тесты (что запускалось и результат):
- Проверки ролей и доступа:
- Изменения данных и миграции:
- Риски:
- План отката:
- Приёмка владельцем:

Критерий готовности

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

Источник: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

Материал был полезен?

Помогите нам сделать материалы точнее и понятнее.