Что такое git stash

git stash нужен в очень обычной рабочей ситуации. У вас есть незавершенные локальные правки, но прямо сейчас нужно получить чистое рабочее дерево. Например, вы делаете форму на React, затем прилетает срочный баг в другой ветке. Коммитить сырой код не хочется, а переключиться Git может не дать из-за конфликтующих файлов.

В этом месте stash сохраняет изменения во временную локальную запись и очищает рабочую директорию. Позже вы возвращаетесь и применяете эту запись обратно.

git status
git stash push -m "checkout form before hotfix"
git switch hotfix/payment

# исправили баг

git switch feature/checkout-form
git stash list
git stash apply stash@{0}

Хороший короткий ответ: stash это не коммит и не отправка на сервер. Это локальный буфер для быстрого переключения контекста.

По умолчанию git stash сохраняет изменения в отслеживаемых файлах. Сюда входят изменения в рабочей директории и в индексе. То есть staged-правки тоже могут попасть в stash.

Важная ловушка: новые файлы, которые Git еще не отслеживает, по умолчанию не сохраняются. Для них нужен флаг -u или полная форма --include-untracked.

# Сохранить изменения в отслеживаемых файлах
git stash push -m "temporary navbar changes"

# Сохранить еще и новые untracked файлы
git stash push -u -m "new modal files"

Для frontend-разработки это не мелочь. Новый компонент, CSS-модуль, тест или mock-файл может остаться в рабочей директории, если вы забыли -u. В итоге переключение ветки не станет чистым. После возврата можно применить только часть правок и получить экран без нужного стиля, теста или вспомогательного модуля.

На интервью полезно показать не только команду, но и критерий выбора. Stash хорош для короткого переключения. Для хранения важной работы на неопределенный срок он подходит плохо.

git stash apply применяет сохраненные изменения, но оставляет запись в списке stash. Это удобно, если вы не уверены, что изменения лягут чисто, или хотите применить их еще раз в другой ветке.

git stash pop применяет изменения и удаляет запись после успешного применения. Если возникли конфликты, запись обычно остается в списке, но все равно не стоит использовать pop вслепую. Сначала проверьте, что применяете нужный stash и находитесь в нужной ветке.

git stash list
git stash apply stash@{1}

# если все хорошо и запись больше не нужна
git stash drop stash@{1}

Формулировка для интервью может быть такой: если есть риск конфликта или я не уверен в записи, я предпочту apply, а потом удалю stash вручную.

Сильный ответ показывает порядок действий. В реальной задаче проблема обычно не в том, что команда забыта. Чаще вы сохранили что-то непонятное, применили не туда и получили смесь изменений.

Плохой вариант выглядит так:

git stash
git switch hotfix
# через день
git switch feature
git stash pop

Это работает, пока у вас одна запись и свежий контекст в голове. Но если за день появилось несколько stash, вы легко примените не тот набор правок. Во frontend-задаче так можно незаметно смешать изменение состояния формы, стили и мок API из разных веток. Лучше дать записи имя, перед восстановлением посмотреть список и начать с apply.

git stash push -u -m "checkout form validation before hotfix"
git stash list
git stash apply stash@{0}

Stash не стоит считать универсальным решением. Если изменения важны, должны быть видны команде или могут понадобиться после перезагрузки контекста, безопаснее сделать ветку и WIP-коммит. Такой коммит можно потом поправить через rebase или squash перед pull request.

Еще один случай: вы хотите перенести изменения между ветками. Stash может помочь, но он не гарантирует бесконфликтное применение. Если файлы в ветках сильно разошлись, придется решать конфликты так же, как при merge или rebase.

Ответ на интервью можно собрать в 3 части. Сначала назначение: временно сохранить незакоммиченные локальные изменения. Затем границы: по умолчанию не все файлы, для untracked нужен -u, для надежности стоит использовать сообщения. В конце риск: pop и применение на другую ветку могут привести к конфликтам или смешиванию задач. Поэтому перед восстановлением нужно смотреть список и статус.

Если вы добавите эту практическую часть, ответ прозвучит как опыт работы с Git, а не как пересказ справки по команде.