GitHub хранит удалённую копию проекта, а Git фиксирует историю изменений. Для вайбкодинга это не формальность: генератор может заменить файл, удалить работающий компонент или обновить зависимости. История позволяет понять, что изменилось, и вернуться к известной версии — если изменения действительно сохранены.
Начни с проверки папки
Открой терминал в корне проекта и сначала выполни git status. Если Git уже управляет папкой, не запускай git init повторно и выясни, какая ветка активна. Если репозитория ещё нет, добавь .gitignore до первого git add: исключи секреты, локальные настройки и созданные зависимости, руководствуясь стеком проекта. Никогда не добавляй .env с ключами поставщиков.
Иллюстративная последовательность для нового локального проекта:
git init
git status
git add .
git diff --cached
git commit -m "Начальная версия"
Перед commit изучи staged diff — именно он попадёт в снимок. Коммит локален. Подключение GitHub remote и git push — отдельные действия, которые могут раскрыть код участникам репозитория; проверь видимость и удалённый адрес до отправки.
Один безопасный цикл изменений
Создай ветку для задачи, попроси агента изменить ограниченный экран и после ответа просмотри git diff. Сравни его с кратким планом: не появились ли новые зависимости, права доступа, запросы к внешним URL или удалённые проверки. Запусти проектные команды, указанные в README, затем зафиксируй понятный коммит. Небольшие коммиты проще сопоставить с конкретной задачей.
Для отмены различай три инструмента. git restore <file> возвращает файл из индекса/другого источника и может удалить незакоммиченную работу. git revert <commit> создаёт новый коммит с обратным изменением и подходит для общей опубликованной истории. git reset передвигает указатель истории и способен убрать коммиты из текущей ветки. Перед любой отменой сначала сохрани нужную работу и прочитай справку команды.
Что не является резервной копией
Текущий браузерный preview — не история. Рабочее дерево без коммита не сохранено в Git; локальный коммит не лежит на GitHub, пока его не отправили. А публичный репозиторий раскрывает весь включённый исходный код. Секрет, попавший в историю, нельзя считать удалённым только потому, что строку позже стерли: сначала отзови/замени секрет, затем разбирайся с историей.
Проверь свежий clone в отдельной папке: установка по README, сборка, запуск и тесты должны работать без скрытых файлов с твоего компьютера. Этот шаг ловит зависимости от незакоммиченной конфигурации и локальных данных. Команды здесь — иллюстрация типичного Git-процесса, а не исполненная в твоём репозитории проверка.
Перед первым push
Сверь git remote -v с ожидаемым владельцем и репозиторием. Для приватного проекта проверь, кто входит в организацию и какие приложения имеют доступ. Первая отправка может передать несколько прошлых коммитов, а не только последний файл. Если секрет случайно попал в коммит, немедленно отзови его у поставщика; последующее удаление из текущего файла не аннулирует значение и не удаляет копии из уже отправленной истории.
Что держать в каждой версии
Коммит должен быть небольшим и описывать действие, например Добавлен фильтр заявок, а не «правки». После теста оставь рабочую ветку в понятном состоянии: чистое дерево либо незакоммиченные правки, которые явно отделены. Перед тем как отдать агенту следующую задачу, зафиксируй предыдущий diff: иначе изменения смешаются и будет сложнее понять, какая часть вызвала регрессию. Для совместной работы GitHub Flow предлагает короткие ветки и review до merge; это не заменяет автоматические проверки, но создаёт понятное место для обсуждения.
Источники: Git — документация, git restore, git revert, GitHub — добавление проекта. Для pull request добавь описание: контекст проблемы, что изменено, как проверял, что намеренно не включено. Разделяй «команда прошла локально» и «GitHub Actions прошёл»: окружение может отличаться, например из-за отсутствующего секрета или базы. Настрой CI без вывода секретных environment variables и без широких write permissions по умолчанию.
Перед merge посмотри, какие файлы конфликтуют, и проверь объединённый результат. После разрешения конфликта повторно запусти нужные тесты: исходные branch checks могли относиться к коду до разрешения. Не объединяй незнакомый generated diff только потому, что конфликт был отмечен зелёным.
Если Git команды пока неудобны, можно начать с GUI-панели редактора, но пойми её аналоги: staged changes, commit, branch, remote, pull request. GUI не отменяет риск; staged diff всё так же показывает, что попадёт в коммит. Сначала сделай упражнение на временном проекте с файлом hello, добавь изменение, создай commit и сравни его в UI. Не изучай восстановление впервые во время аварии.