Спочатку зупиніть лавину

Після невдалої AI-правки не слід одразу просити Claude «виправити все». Спершу встановіть фактичний масштаб проблеми через Git: активну гілку, змінені файли, diff і останні коміти.

Мінімальний відкат безпечніший за повторне редагування поверх хаотичного diff. Маленькі milestone-коміти здешевлюють відновлення.

git status
git diff -- path/to/file
git diff
git log --oneline -3

Відновлення залежить від місця змін

СтанПідхід
Робочі файлиПереглянути diff і за потреби обережно використати git restore
Staging areaСпочатку git restore --staged, потім оцінити файл
Поганий коміт у shared historyСтворити новий коміт через git revert
Поганий локальний комітРозглянути reset лише якщо історію ще не бачила команда
Заплутана гілкаСтворити нову гілку від чистої бази

Мінімальний Git-first recovery

  1. Припиніть нові AI-правки.
  2. Перевірте git status і перегляньте підозрілі фрагменти diff.
  3. Відокремте потрібні зміни від зайвих.
  4. Оберіть найменший безпечний спосіб rollback.
  5. Запустіть релевантні тести.
  6. Повторно перевірте diff.
  7. Дайте Claude нове вузьке завдання з явними межами.
Обережне відновлення робочого файла
git restore path/to/file
git status
git diff

Чиста база для повторної спроби

Стара гілка може залишитися джерелом окремих корисних ідей, але нову реалізацію краще почати з чистої бази, якщо попередній diff уже важко пояснити.

git switch -c refund-refactor-retry main

Зовнішні ефекти не відкотяться разом із Git

  • Git відновлює файли й історію, але не скасовує міграцію бази.
  • Відкат коду не повертає зовнішній виклик або вже виконаний деплой.
  • Для shared history безпечнішим за переписування зазвичай є git revert.
  • Перед git restore переконайтеся, що незбережені зміни справді зайві.

Канонічне джерело уроку · JavaRush

Відкрити матеріал JavaRush