Ошибка 1: git reset --hard без резервной копии
Одна из самых распространённых причин потери работы.
⚠️ ОПАСНО: git reset --hard
Типичные сценарии потери данных:
— Запустили
— Перепутали ветку и сделали reset --hard на main
— Хотели «просто очистить» рабочий каталог, но удалили незакоммиченные изменения
Безопасные альтернативы:
—
—
—
—
git reset --hard HEAD~1 или git reset --hard <commit> безвозвратно удаляет ВСЕ изменения в рабочем каталоге и индексе — включая несохранённые правки файлов. После выполнения этой команды восстановление данных без внешних резервных копий невозможно.Типичные сценарии потери данных:
— Запустили
git reset --hard не разобравшись, что это сделает— Перепутали ветку и сделали reset --hard на main
— Хотели «просто очистить» рабочий каталог, но удалили незакоммиченные изменения
Безопасные альтернативы:
—
git reset --soft HEAD~1 — откатывает коммит, сохраняет изменения в staging—
git reset --mixed HEAD~1 — откатывает коммит, сохраняет изменения в рабочем каталоге—
git stash — временно спрятать изменения перед reset—
git revert — безопасная отмена через новый коммит
Ошибка 2: git push --force на публичной ветке
Возникает чаще всего после rebase, когда Git не позволяет обычный push.
⚠️ ОПАСНО: git push --force
— Невозможности выполнить обычный
— Потере чужих коммитов, влитых после вашего последнего pull
— Конфликтам и путанице в истории проекта
Никогда не использовать
Более безопасная альтернатива для защищённых публичных веток:
git push --force (или git push -f) перезаписывает историю удалённого репозитория вашей локальной историей. Все разработчики команды, которые уже получили предыдущие коммиты, окажутся в ситуации, когда их локальная история расходится с удалённой. Это приведёт к:— Невозможности выполнить обычный
git pull— Потере чужих коммитов, влитых после вашего последнего pull
— Конфликтам и путанице в истории проекта
Никогда не использовать
git push --force на ветках main, master, develop и других ветках, с которыми работает команда.Более безопасная альтернатива для защищённых публичных веток:
git push --force-with-lease — отказывает, если удалённая ветка изменилась с момента вашего последнего fetch, что предотвращает перезапись чужих коммитов.
Ошибка 3: rebase публичной (общедоступной) ветки
Нарушение золотого правила rebase — самая дорогостоящая командная ошибка.
Что происходит: Вы выполняете
Когда вы пытаетесь запушить, Git отказывает. Единственный способ отправить изменения —
Правило: Перед
git rebase на ветке main (или другой общедоступной ветке). Rebase создаёт новые коммиты с теми же изменениями, но другими хэшами. Ваша ветка «расходится» с удалённой.Когда вы пытаетесь запушить, Git отказывает. Единственный способ отправить изменения —
git push --force, что разрушает историю для всех.Правило: Перед
git rebase всегда спросите себя: «Кто-нибудь ещё работает с этой веткой?» Если да — используйте git merge.
Ошибка 4: Путаница между reset и revert
| Ситуация | Правильная команда | Почему |
|---|---|---|
| Нужно отменить коммит на main (публичная ветка) | git revert <hash> |
Создаёт новый коммит; история не меняется; команда видит отмену |
| Нужно отменить последний коммит на локальной ветке | git reset --soft HEAD~1 |
Коммит отменяется; изменения остаются и можно исправить |
| Нужно полностью убрать последний коммит И изменения (личная ветка!) | git reset --hard HEAD~1 |
Только если 100% уверены, что изменения не нужны и ветка локальная |
Ошибка 5: git commit --amend после push
После того как коммит был запушен в удалённый репозиторий, git commit --amend изменяет его хэш (создаёт новый коммит). Это приведёт к расхождению с удалённой веткой, и Git откажет при следующем push.
# Плохой сценарий:
git push origin feature # коммит ушёл на сервер
git commit --amend -m "Oops" # изменяем хэш коммита
git push origin feature # ОШИБКА: rejected, non-fast-forwardПравило: git commit --amend — только для коммитов, которые ещё не были запушены.