Базовый цикл: спрятать, посмотреть, вернуть
Команда git stash (она же git stash push) сохраняет изменения отслеживаемых файлов в стек и откатывает рабочую копию к состоянию HEAD. После этого ветку можно менять свободно: конфликтов с незакоммиченными правками не будет.
git stash push -m 'wip: правки формы'
git stash list
git stash show -p stash@{0}
git stash poppop возвращает изменения и удаляет запись из стека, apply возвращает, но оставляет запись на месте. Второй вариант безопаснее: если правки не лягут на изменившийся код, вы хотя бы не останетесь без копии. Метка через -m помогает опознать запись в списке — без неё git stash list выглядит как набор одинаковых строк с сообщением ветки.
Стек локальный и общий для всего репозитория, к ветке он не привязан. Технически можно спрятать правки в одной ветке, а применить в другой, но рассчитывайте на конфликты, если код в этих ветках разошёлся.
Что не попадает в stash по умолчанию
Стандартный stash берёт только изменения уже отслеживаемых файлов. Новые файлы, которые Git ещё не видел, останутся в рабочей копии — при переключении ветки они никуда не денутся и могут помешать. Чтобы захватить и их, нужен флаг -u (--include-untracked):
git stash push -u -m 'новые файлы и правки'Флаг -a (--all) дополнительно забирает файлы из .gitignore. Пользоваться им стоит осторожно: в stash попадут node_modules, сборки, локальные конфиги, а при возврате всё это разом окажется в рабочей копии. Если такие файлы не нужны в истории правок, лучше обойтись -u.
Иногда спрятать надо не всё, а часть. git stash push принимает пути, а -p открывает интерактивный выбор по ханкам, как git add -p:
git stash push -m 'только конфиг' -- config/local.php
git stash push -pЧастичный stash удобен, когда в одном файле смешаны правки для разных задач. Минус в том, что при возврате такие записи конфликтуют чаще: соседние строки уже изменились, и Git не всегда может аккуратно совместить ханки.
Альтернативы, когда прятать нечего или нельзя
WIP-коммит (git commit -am 'wip') оставляет изменения в истории ветки. Их видно в логах, они переживут сбой машины и уедут в remote при push, но засоряют историю и требуют потом rebase или amend. Для уборки на десять минут stash чище, для работы, которая растянется на дни, коммит надёжнее — он не потеряется при git stash clear.
| Способ | Где оказываются правки | Когда подходит | Ограничения |
|---|---|---|---|
| git stash | локальный стек | быстро переключить ветку, забрать pull | не видно в истории, запись легко забыть, на другую машину не переносится |
| WIP-коммит | ветка репозитория | длинная пауза, нужна страховка | мусор в истории, правки уйдут в push |
| git worktree | отдельная рабочая директория | параллельная работа над двумя ветками | нужна лишняя папка, одну ветку нельзя открыть дважды |
| git diff > file.patch | файл на диске | перенос правок на другую машину | применяется вручную, метаданные не сохраняются |
git worktree add ../hotfix hotfix-branch создаёт вторую рабочую копию репозитория в соседней папке. Текущие незакоммиченные правки остаются на месте, а срочная задача делается в отдельной директории — прятать вообще ничего не нужно. Это удобно, если правок много и возвращать их через stash рискованно, но требует дисциплины: забытые worktree занимают место и путают при переключении.
Если при возврате конфликт или запись потерялась
Если pop упёрся в конфликт, запись остаётся в стеке — Git не удаляет её при неудачном применении. Разбирайте конфликт как обычный merge, а после разрешения удалите запись вручную через git stash drop. Отдельный путь для сложного случая — создать ветку от того коммита, где stash был сделан:
git stash branch fix-from-stash stash@{0}Команда переключится на новый коммит-ответвление и применит правки на чистом коде, где конфликтов меньше. Если запись уже удалена через drop или clear, объекты какое-то время остаются в репозитории недостижимыми: их можно поискать через git fsck --unreachable --no-reflogs и попробовать применить найденный хеш командой git stash apply <hash>. Это не гарантия — после сборки мусора объекты исчезают окончательно.
Стек stash живёт только в вашем локальном клоне. В другом клоне или на другом компьютере git stash list будет пустым, даже если репозиторий синхронизирован.
Частые вопросы
Можно ли перенести stash на другой компьютер? Напрямую нет. Соберите патч (git diff > changes.patch, с -u не забывайте про новые файлы) и примените на другой машине через git apply changes.patch. Патч не сохраняет историю и сообщения, зато переносится любым способом, включая мессенджер.
Чем stash отличается от обычного коммита? Stash — это коммит-объект, но он не входит в историю ветки и не виден в git log. Он не уедет в remote, не попадёт в ревью и не сломает сборку, пока вы сами его не примените.
Как скрыть файл от git status насовсем? Для новых файлов достаточно .gitignore. Для уже отслеживаемых работает git update-index --skip-worktree <файл>, обратная операция — --no-skip-worktree. Флаг локальный, другим не передаётся, и правки в таком файле не попадут в коммит, даже если они нужны. Для локальных конфигов с паролями это компромисс, а не полноценное решение.
Сколько записей можно держать в стеке? Жёсткого лимита нет, но список из десятков строк нечитаем, а старые записи забываются и конфликтуют при возврате. Держите одну-две активные и удаляйте лишние через git stash drop.
Если правки нужны в ближайшие часы, хватит git stash push -u -m с понятной меткой, а возвращайте через apply, чтобы не потерять запись при конфликте. Если работа важная или затянется на дни, заведите отдельную ветку и закоммитьте туда: история переживёт переключения, сбои и очистку стека. Перед drop или clear пролистайте git stash show -p — отменить очистку обычными командами не получится.
