Git и Cursor: как работать безопасно

Agent в Cursor умеет менять десятки файлов за один прогон: search, edit, terminal, иногда commit (overview). Checkpoints откатывают файлы внутри сессии, но не заменяют историю между вечерами и не спасают, если вы уже смержили хаос в main. Отдельная git ветка сужает blast radius до одной задачи: худший сценарий - удалить ветку и начать с чистого main.

Почему предприниматели боятся агента - не из-за «ИИ опасен», а из-за необратимости. Пока правки живут в main без commit и без diff, любая строка от модели ощущается как потеря CRM или бота. Когда есть ветка feat/lead-form и commit «до агента», паника падает: вы сравниваете с main, смотрите только scope задачи, merge только после verify.

Я разделяю три слоя страховки. Первая - ветка или worktree: изолированный checkout, main не трогается (worktrees). Вторая - маленькие git commit после каждого зелёного шага. Третья - git diff до Accept и Apply All. Cursor git в этом смысле не отдельный продукт: Source Control в боковой панели показывает те же staged и unstaged, что и git status в терминале.

На новостных разборах всплывает отдельный риск: публичные логи агента, куда случайно попали пароли из промпта или из файла, который агент прочитал через terminal. Угол простой - не кормить секретами ни чат, ни rules, ни сырые trajectory наружу. Cloud Agent умеет redact runtime secrets (security), но это не отменяет здравый смысл: ключ в промпте уже ушёл в историю сессии.

Пять причин завести ветку до первого промпта:

1. 01

   Откат = git switch main и удаление ветки, а не ручной поиск по backup.

2. 02

   Diff с main виден в Source Control и через @Branch (Diff with Main) в промпте (prompting).

3. 03

   Параллельные задачи не перемешиваются в одной рабочей копии.

4. 04

   Worktree в Cursor держит main checkout нетронутым до Apply после ревью.

5. 05

   Правила и команды в git переживают сессию - агент не «забывает» запреты (agent best practices).

Соло-разработчику ветка нужна не ради команды ревьюеров, а ради эксперимента. Агент может уверенно ошибаться - ветка делает ошибку локальной. Подробный вечерний сценарий с Plan и checkpoint - в первом проекте в Cursor.

Правило, которое я даю на наставничестве: одна задача агента = одна ветка. Не «починим всё в main», а feat/telegram-webhook или fix/landing-hero от актуального main. Имя короткое, по смыслу задачи, без пробелов - так проще искать в истории и в PR.

Через терминал

Минимальный сценарий перед Agent:

git switch main
git pull --ff-only
git checkout -b feat/lead-form-validation
git status

git checkout -b создаёт ветку и сразу переключается на неё - классический способ завести git новую ветку от свежего main. Если main локально устарел, сначала pull, иначе ветка отойдёт от remote и merge потом будет больнее.

Commit «до агента» фиксирует чистое состояние:

git add -A
git commit -m "checkpoint: before agent session"

Теперь любой сбой агента отсекается сравнением с этим commit, а не с памятью «как было вчера».

Через Source Control в Cursor

Не обязательно помнить все флаги. В боковой панели Source Control: клик по имени ветки внизу статус-бара или в шапке SCM → Create new branch → введите feat/короткое-имя → переключиться. Stage изменений кнопкой +, Commit с сообщением. UI git checkout здесь делает то же, что git switch -c в shell.

Для CRM-бота я обычно именую ветку по handler или экрану: fix/bot-lead-handler, для лендинга - feat/hero-cta. Для WordPress child-темы - fix/contact-form-template. Scope в имени ветки напоминает, зачем открывали Agent.

Worktree: когда main вообще не трогать

Cursor умеет запускать агента в отдельном worktree - второй checkout того же репо в другой папке (worktrees). Main checkout остаётся на месте; после ревью - /apply-worktree, после отказа - /delete-worktree. Удобно, если вы параллельно правите hotfix в main и эксперимент с агентом в изоляции.

Типичный порядок для бизнес-репо:

Перед промптом проверяю: git branch --show-current не показывает main. Если показывает - стоп, сначала ветка. Агенту в rules можно явно написать: «работаем только в текущей feature-ветке, не merge в main без моего OK».

Agent закончил прогон - не жму Accept All сразу. Сначала открываю Source Control или git diff в терминале. git diff показывает построчные изменения: что добавил агент, что удалил, не попали ли в diff .env или package.json без согласования. Только после просмотра - Accept по файлам или группам.

Маленький git commit после каждого зелёного verify лучше одного гигантского «агент сделал всё». История превращается в лестницу отката: три коммита по одной фиче проще откатить, чем один ком на сорок файлов. На разборе типичный сценарий: агент поменял двенадцать файлов, я принял восемь, четыре откатил через git restore - и только потом commit принятого.

Порядок, который держу сам и даю ученикам:

1. 01

   Agent завершил шаг - пауза перед Apply.

2. 02

   git diff --stat - ширина изменений в одну строку на файл.

3. 03

   Пофайловый diff в UI или git diff path/to/file.

4. 04

   Accept только файлов из scope задачи.

5. 05

   npm run lint и npm test из вашего package.json - вручную, не по словам чата.

6. 06

   git add точечно, не git add -A вслепую, если агент задел лишнее.

7. 07

   git commit -m "feat: описание одного шага".

Перед Accept All полезен жёсткий smoke на секреты в diff:

git diff | grep -E '\.env|SECRET|TOKEN|password|api[_-]?key' \
  && echo "STOP: проверьте diff на секреты" && exit 1 || true

Это грубый фильтр, не замена secret scanner, но на разборе ловит «временный ключ в config.ts». Полный чеклист ревью - в как проверять код от ИИ.

Таблица «когда коммитить»:

Checkpoints в Agent - быстрый undo внутри сессии. git commit - постоянная история. Оба слоя полезны, но не взаимозаменяемы: checkpoint не спасёт после закрытия редактора, если вы не закоммитили принятое.

Если агент предлагает сам выполнить git commit через terminal - смотрю diff до выполнения. В rules можно запретить автокоммит без вашего подтверждения. Человек остаётся на этапе «что попало в историю».

Файл gitignore в корне репо говорит Git не отслеживать перечисленные пути - но только неотслеживаемые файлы (gitignore). Если .env уже попал в commit раньше, одна строка в ignore не вытащит его из истории. Нужен git rm --cached .env, ротация секрета и при утечке - чистка истории или смена ключей.

До первого коммита в новом репо я проверяю шаблон ignore:

.env
.env.*
.env.local
secrets/
*.pem
*.key
credentials.json
config.local.*
node_modules/
dist/
coverage/
.DS_Store

Дублирую чувствительные пути в .cursorignore - тогда Agent, Tab и @ не подтянут файл в контекст (ignore-file). Важная оговорка из доки: .cursorignore не security boundary. Terminal и MCP теоретически могут прочитать игнорированный файл, если агент выполнит shell-команду. Нужны approvals на команды и не просить cat .env в задаче.

Что не отдавать агенту ни в чат, ни в rules, ни во вложения:

• значения TELEGRAM_BOT_TOKEN, DATABASE_URL, API-ключи;
• содержимое credentials.json, приватные ключи;
• production-дампы БД и логи с PII;
• сырые agent transcripts и trajectory, если там могли оказаться секреты из скрытых блоков reasoning.

В промпт - имена переменных, не значения. В репо - .env.example с пустыми или фейковыми строками. Если агент «для примера» вставил токен в src/config.ts - это не «временно», это утечка в diff.

Чеклист до первого Agent в новом репо:

1. 01

   .gitignore и .cursorignore созданы до git add.

2. 02

   git status не показывает .env в untracked, который вы собираетесь закоммитить.

3. 03

   Нет tracked секретов - если есть, git rm --cached и ротация.

4. 04

   В rules строка: не читать и не коммитить .env*.

5. 05

   GitHub push protection включена для public - страховка против push с ключами (push protection), не 100% защита.

6. 06

   Проверка git diff перед каждым commit.

На разборе видел типичный сценарий: ученик вставил токен бота в промпт «чтобы заработало», потом запушил ветку. Откат - ротация ключа и удаление из истории, не «удали строку в Cursor». Профилактика дешевле лечения.

Если секрет уже в истории - ignore постфактум не спасает. План: отозвать ключ, git rm --cached, при публичном репо - BFG или support GitHub, новый ключ в vault, не в коде. Агенту не поручаю «почисти историю git» без вашего контроля - слишком легко снести лишнее.

Работа в main без ветки превращает каждый прогон Agent в русскую рулетку для продакшена. Агент может закоммитить, запушить, смешать полуфабрикат с рабочим кодом - и вы узнаете об этом только после деплоя или падения тестов у клиента. Ниже не абстрактные советы, а пары симптом-причина-фикс с разборов.

Прод на main перезаписан

Сценарий: сайт на Vite, вы работали в main «потому что один человек». Agent обновил роутинг, сломал сборку, закоммитил. Деплой с GitHub Actions ушёл на хостинг. Симптом - 404 на странице оплаты. Причина - прямой commit в main без preview и без verify. Фикс: git log на один-два коммита назад, git revert для плохого commit на shared main или git reset --hard только если main ещё не пушили. Дальше - жёсткое правило: main только через merge после review, локально агент только в ветке.

Если main уже на remote и другие тянут репо - не force-push без согласования. Revert создаёт обратный commit, история остаётся честной для команды.

Секреты попали в историю коммитов

Сценарий: агент прочитал .env через terminal, скопировал строку в config.ts «для теста», вы закоммитили вместе с фичей. Симптом - ключ в git log -p или сработал secret scanner. Причина - секрет был доступен агенту и не был в ignore до сессии; tracked-файл ignore не скрывает. Фикс: немедленная ротация ключа; удаление из рабочей копии; git rm --cached; для публичного репо - очистка истории. .gitignore после утечки - только профилактика на будущее.

Публичные логи агента - отдельный канал утечки: не выкладывайте trajectory, если в промпт попадали пароли. Даже если в чате их не видно, в скрытых блоках reasoning они могут остаться - проверьте, что не светите сырые логи.

Непонятный merge или rebase от Agent

Сценарий: агент «помог» с git, выполнил git pull --rebase, конфликты в пяти файлах, половина с маркерами <<<<<<<. Симптом - проект не собирается, статус «rebase in progress». Причина - автономный terminal без вашего контроля ветки. Фикс: git rebase --abort или git merge --abort, вернуться на commit «до агента»; запретить в rules произвольный rebase/merge; ветка изолирована от main до вашего merge вручную.

Если агент уже запушил испорченную ветку - не мержите PR. Удалите remote-ветку, локально пересоздайте от чистого main, повторите задачу с узким scope.

Когда Agent ушёл не туда, git откатить изменения можно на разных уровнях - от «не принял в UI» до «убрать commit из истории». Главное - на какой ветке вы стоите и пушили ли уже на shared remote.

Непринятые правки в рабочей копии

Если Agent предложил diff, но вы ещё не нажали Accept - отклоните в UI или закройте без сохранения. Если файлы уже изменены на диске, но не в commit:

git restore path/to/file.ts
# или все unstaged:
git restore .

git restore откатывает рабочую копию к последнему commit (git-restore). Для staged, но не закоммиченных:

git restore --staged path/to/file.ts
git restore path/to/file.ts

Откат последнего commit на своей ветке

Если агент закоммитил, но вы ещё не пушили - на локальной feature-ветке допустим git reset:

git log --oneline -3
git reset --hard HEAD~1

HEAD~1 снимает один последний commit. Все изменения из него исчезнут из ветки - убедитесь, что там не было нужного вручную. Мягкий вариант - git reset --soft HEAD~1: commit исчезает, изменения остаются staged.

Как откатить коммит, который уже ушёл на GitHub и main общий с коллегой - через git revert <hash>, не через force-push. Revert создаёт новый commit, отменяющий плохой. Так безопаснее для shared main.

Сценарий «12 файлов, часть принял»

Типичный recovery с разбора: агент изменил двенадцать файлов, восемь полезны, четыре - мусор. Я смотрю git diff, Accept только нужные в UI, для остальных git restore . по путям или откат к commit «до агента» и ручной перенос хороших hunks. Занимает около пяти минут при дисциплине ветки - не часы на восстановление main.

Таблица отката:

На shared main без согласования не делаю reset --hard и не force-push - только revert или откат через админа репо. Solo на своей ветке - reset допустим, пока не открыли PR.

Ниже чеклист, который я прохожу сам перед сессией с Agent в клиентском репо. Не курс Git на двадцать часов - минимум, чтобы агент не превратил вечер в восстановление продакшена.

До открытия Agent:

1. 01

   git switch main и git pull - база актуальна.

2. 02

   git checkout -b feat/задача-дня - не работать в main.

3. 03

   Commit «checkpoint: before agent» на чистом дереве.

4. 04

   .gitignore и .cursorignore закрывают .env*, ключи, node_modules.

5. 05

   В rules или AGENTS.md: scope путей, verify-команды, запрет автокоммита в main.

6. 06

   Промпт сузить: задача + 1-3 @ на entrypoint (как ставить задачи Cursor Agent).

Во время сессии:

1. 01

   Diff после каждого крупного шага - до Apply All.

2. 02

   lint/test вручную в терминале.

3. 03

   Маленькие commit только после зелёного verify.

4. 04

   Не вставлять секреты в чат и не публиковать сырые логи сессии.

После сессии:

1. 01

   Финальный git diff main - ширина изменений ожидаема.

2. 02

   Merge в main только локально или через PR после вашего review.

3. 03

   При Cloud Agent - draft PR и ревью человека (security).

Код-напоминание для терминала в одну строку после сессии:

git diff --stat && npm run lint && npm test && git status

Если что-то красное - не merge, не push. Сначала фикс или откат.

Когда репозиторий чужой и процесс под ключ - смотрю разработку проектов как отдельный трек; для своего вечернего цикла достаточно ветки и diff. По теме в блоге: первый проект в Cursor - вечер с нуля; как проверять код от ИИ - после diff; как ставить задачи агенту - узкий промпт.

Три возражения, которые слышу чаще всего: