Как работает git reset?

Как работает git reset

git reset — это мощная команда Git, которая перемещает указатель HEAD и может изменять состояние файлов. Это одна из самых важных команд для управления историей коммитов. Давайте разберемся, как она работает и какие режимы у неё есть.

Что такое git reset

git reset перемещает текущую ветку на другой коммит и может изменять состояние файлов в рабочей директории и индексе (staging area). Это отличается от других команд — она может безопасно отменять последние коммиты.

Три режима git reset

У команды есть три основных режима, которые определяют, как будут обработаны файлы:

1. git reset --soft (мягкий сброс)

Что происходит:

• Перемещает HEAD на другой коммит
• Изменения остаются в staging area (индекс не изменяется)
• Рабочая директория не меняется
• Все файлы остаются в состоянии "готово к коммиту"

# История:
# A - B - C (HEAD)

git reset --soft HEAD~1

# После:
# A - B (HEAD)
# Изменения из C остаются в staging area
# Можно сделать git commit для переделки коммита

Практический пример:

# Предположим, вы сделали коммит, но забыли добавить файл
git add file1.js
git commit -m "Add feature"

# Потом вспомнили ещё об одном файле
git add file2.js

# Вернуть коммит в staging, чтобы добавить оба файла вместе
git reset --soft HEAD~1
git add file2.js
git commit -m "Add feature with file2"

2. git reset --mixed (смешанный сброс) - ПО УМОЛЧАНИЮ

Что происходит:

• Перемещает HEAD на другой коммит
• Удаляет изменения из staging area
• Рабочая директория НЕ меняется (файлы остаются)
• Нужно снова сделать git add

# История:
# A - B - C (HEAD)

git reset --mixed HEAD~1
# или просто:
git reset HEAD~1

# После:
# A - B (HEAD)
# Изменения из C находятся в рабочей директории
# но не в staging area (не готовы к коммиту)

Практический пример:

# Вы добавили несколько изменений в staging
git add file1.js file2.js file3.js
git status
# Changes to be committed: file1.js, file2.js, file3.js

# Но передумали и хотите разделить на несколько коммитов
git reset  # или git reset --mixed (по умолчанию)

# Теперь файлы в рабочей директории, но не в staging
git add file1.js
git commit -m "Feature 1"

git add file2.js file3.js
git commit -m "Feature 2 and 3"

3. git reset --hard (жёсткий сброс) - ОПАСНО!

Что происходит:

• Перемещает HEAD на другой коммит
• Удаляет изменения из staging area
• УДАЛЯЕТ все изменения в рабочей директории
• Файлы возвращаются в состояние целевого коммита
• Потеря данных возможна!

# История:
# A - B - C (HEAD)

git reset --hard HEAD~1

# После:
# A - B (HEAD)
# Все изменения из C полностью удалены
# Рабочая директория соответствует коммиту B

ОПАСНЫЙ пример:

# Вы много работали
git add file1.js file2.js file3.js
# ... много кода ...

# Ошибка! Вы сделали:
git reset --hard HEAD~1

# ВСЕ ВАШ КОД ПОТЕРЯЕТСЯ! (если не было коммита)
# Используйте только когда уверены!

Когда использовать --hard:

# 1. Отменить все несохранённые изменения (использовать осторожно)
git reset --hard HEAD

# 2. Вернуть ветку в состояние удалённого репозитория
git reset --hard origin/main

# 3. Удалить последний коммит (если он создан ошибкой)
git reset --hard HEAD~1

Таблица сравнения режимов

Синтаксис git reset

# Базовый синтаксис
git reset [режим] [коммит]

# Примеры:
git reset --soft HEAD~1         # На 1 коммит назад (soft)
git reset --mixed HEAD~2        # На 2 коммита назад (mixed)
git reset --hard HEAD~3         # На 3 коммита назад (hard)

# С конкретным коммитом
git reset --soft abc1234        # На конкретный коммит

# Для отдельного файла (не меняет HEAD)
git reset HEAD file.js          # Удалить файл из staging
git reset HEAD -- file.js       # Явно указать файл

Практические примеры

Пример 1: Исправить последний коммит

# Вы коммитили, но забыли добавить файл
git commit -m "Feature X"

# Решение:
git reset --soft HEAD~1
git add forgotten_file.js
git commit -m "Feature X"

Пример 2: Разделить коммит на несколько

# История:
# A - B - C (HEAD) - большой коммит с 3 фичами

# Вернуть всё в рабочую директорию
git reset HEAD~1

# Теперь сделать 3 отдельных коммита
git add feature1/
git commit -m "Feature 1"

git add feature2/
git commit -m "Feature 2"

git add feature3/
git commit -m "Feature 3"

Пример 3: Отменить последний коммит (если не pushed)

# Вы сделали коммит, но он ошибочный
git reset --soft HEAD~1

# Или удалить коммит и все изменения (BE CAREFUL!)
git reset --hard HEAD~1

Пример 4: Вернуть файл к состоянию в staging area

# Вы отредактировали файл
echo "new content" > file.js

# Хотите отменить изменения (но не удалить файл)
git reset HEAD file.js          # Убрать из staging
git checkout -- file.js         # Или git restore

git reset vs git revert

Важное отличие:

# git reset - МЕНЯЕТ историю (опасно для shared веток)
git reset --hard HEAD~1
# История: A - B - C становится A - B

# git revert - ДОБАВЛЯЕТ новый коммит (безопасно)
git revert HEAD
# История: A - B - C - D (где D отменяет C)

Правило:

• Используйте git reset только для локальных веток
• Используйте git revert для shared веток (уже pushed)

Восстановление после неудачного reset

# Если вы случайно сделали git reset --hard
# Можно восстановить через git reflog

git reflog
# Найдите нужный коммит

git reset --hard abc1234  # Вернуться на нужный коммит

Безопасный рабочий процесс

# 1. Перед опасной операцией создать backup ветку
git branch backup-branch

# 2. Проверить, что вы на правильной ветке
git branch
# * main

# 3. Проверить статус
git status

# 4. Просмотреть историю
git log --oneline -5

# 5. Только потом использовать reset
git reset --hard HEAD~1

# 6. Если что-то пошло не так
git reset --hard backup-branch

Резюме

git reset --soft:

• Используй для переделки коммитов
• Безопасен — изменения остаются

git reset --mixed (по умолчанию):

• Используй для unstage файлов
• Изменения остаются в рабочей директории

git reset --hard:

• ТОЛЬКО для отмены изменений
• ОПАСЕН — полная потеря данных
• Используй только если уверен

Золотое правило: Никогда не используй git reset --hard на shared ветках (main, develop). Используй git revert вместо этого.