Олег Марков
Сохранение с сообщением в Git - git stash save
Введение
Команда git stash часто воспринимается как «чёрный ящик» для временного хранения изменений. Многие разработчики знают лишь базовое применение, но не используют дополнительные возможности, такие как сохранение стэша с осмысленным сообщением. В результате через пару дней в репозитории лежит несколько безымянных стэшей, и уже невозможно вспомнить, что в каждом из них.
Здесь мы разберём подход «Сохранение с сообщением» с помощью команды git stash save и её современных аналогов. Смотрите, я покажу вам, как правильно сохранять стэши с понятным описанием, чем git stash save отличается от новых форм, какие есть опции, и как эти знания помогут вам безопасно переключаться между задачами, не теряя незакоммиченные изменения.
Что такое git stash и зачем нужно сообщение
Кратко о механике git stash
Git хранит вашу историю в виде коммитов. Но часто возникают ситуации, когда вы:
- начали правки в файлах;
- ещё не готовы делать коммит;
- внезапно нужно переключиться на другую ветку или задачу.
Командой:
git stash
Git:
- создает один или два служебных коммита (в зависимости от режима);
- переносиt текущие незакоммиченные изменения в специальный внутренний список (stash list);
- откатывает рабочее дерево и индекс к последнему коммиту.
То есть ваши изменения не исчезают, а «прячутся» в отдельном стэше.
Зачем вообще нужно сообщение у стэша
По умолчанию git stash создаёт записи примерно такого вида:
$ git stash list
stash@{0}: WIP on feature/login: 1a2b3c4 Add login controller
stash@{1}: WIP on develop: 5d6e7f8 Initial commit
Git автоматически добавляет текст WIP on <ветка>: <хеш> <сообщение_коммита>. Но такая подпись:
- не отражает суть правок;
- плохо помогает, если у вас много параллельных задач на одной ветке;
- со временем превращает список стэшей в непонятный набор записей.
Сохранение с сообщением позволяет явно указать, что именно вы откладываете:
git stash save "Фикс валидации формы регистрации"
Теперь в списке будет понятная подпись, и через несколько дней вы быстро поймёте, где какие изменения.
Команда git stash save и её статус в современных версиях Git
Почему git stash save считается устаревающим способом
Исторически команда git stash имела подкоманду save:
git stash save "сообщение"
Начиная с современных версий Git, save считается устаревающей формой записи. Сейчас рекомендации такие:
использовать краткую форму:
git stash push -m "сообщение"или даже просто:
git stash -m "сообщение"
Команда git stash save всё ещё работает во многих версиях Git, но официальная документация помечает её как устаревшую (deprecated) и рекомендует использовать git stash push.
Давайте разберём оба варианта, чтобы вы понимали различия и могли уверенно использовать любой из них в текущем окружении.
Базовый синтаксис git stash save с сообщением
Общая форма команды
Классический синтаксис:
git stash save "Ваше сообщение о стэше"
Смотрите, что делает эта команда:
- сохраняет только отслеживаемые файлы (tracked);
- по умолчанию также включает проиндексированные изменения (staged);
- очищает рабочее дерево и индекс — оставляет проект в состоянии последнего коммита.
Пример:
// Изменили файл main.go и файл config.json
// Уже добавили main.go в индекс
git add main.go
// Сохраняем изменения в стэш с сообщением
git stash save "Фикс логики запуска сервиса"
// После этого:
// - main.go и config.json вернутся к состоянию последнего коммита
// - изменения окажутся в стэше с указанным сообщением
Где отображается сообщение
Давайте посмотрим, как сообщение проявляется в списке стэшей:
git stash save "Фикс логики запуска сервиса"
git stash save "Эксперименты с новым конфигом"
git stash list
Примерный вывод:
stash@{0}: On feature-run-service: Фикс логики запуска сервиса
stash@{1}: On feature-run-service: Эксперименты с новым конфигом
Обратите внимание:
- вместо
WIP onиспользуется префиксOn; - далее идёт имя ветки;
- после двоеточия будет то сообщение, которое вы указали.
Использование git stash push -m как современная альтернатива
Почему лучше привыкать к git stash push -m
git stash push — более гибкий и современный способ работы со стэшами. Он:
- поддерживает те же опции, что и
save, и даже больше; - позволяет явно передавать пути файлов, которые вы хотите застэшить;
- имеет более предсказуемое поведение в новых версиях Git.
Базовый эквивалент git stash save "msg":
git stash push -m "msg"
Работает практически так же, но у вас появляются дополнительные возможности.
Пример с выборочным стэшированием файлов
Покажу вам, как это реализовано на практике:
// Изменили два файла
// src/app.js и docs/readme.md
// Сохраняем в стэш только изменения в src/app.js с сообщением
git stash push -m "Черновик новой логики" src/app.js
// В результате:
// - изменения в src/app.js попадут в стэш
// - изменения в docs/readme.md останутся в рабочем каталоге
Это удобно, если вы хотите временно отложить только часть изменений, а остальное продолжать редактировать.
Важные опции git stash save и их аналоги в push
Опция -k или --keep-index
Иногда вам нужно:
- сохранить в стэш только неиндексированные изменения;
- оставить те изменения, которые уже попали в индекс (staged), чтобы их можно было сразу закоммитить.
Для этого используется опция --keep-index:
git stash save --keep-index "Сообщение стэша"
Аналог через push:
git stash push -m "Сообщение стэша" --keep-index
Давайте разберёмся на примере:
// Изменили два файла
// 1) src/main.go
// 2) src/utils.go
// Добавили только src/main.go в индекс
git add src/main.go
// Выполняем:
git stash push -m "Спрятать незавершённые правки в utils" --keep-index
Что произойдёт:
- изменения в
src/utils.goуйдут в стэш; - изменения в
src/main.goостанутся в индексе и рабочем каталоге; - вы можете сразу сделать
git commitдляsrc/main.go; - незавершённые изменения в
src/utils.goждут вас в стэше.
Это полезно, когда вы хотите разделить правки на два логичных набора: один закоммитить, другой отложить.
Опция -u или --include-untracked
По умолчанию git stash save не трогает неотслеживаемые файлы (untracked), то есть те, которые ещё не добавлены через git add. Например:
- новые файлы;
- временные файлы;
- черновики.
Если вы хотите сохранить их тоже, используйте -u:
git stash save -u "Сохранить и отслеживаемые и неотслеживаемые файлы"
Аналог через push:
git stash push -u -m "Сохранить и отслеживаемые и неотслеживаемые файлы"
Теперь в стэш попадут:
- изменения в отслеживаемых файлах;
- новые файлы, которые ещё не были добавлены в индекс.
Пример:
// Создали новый файл
touch draft.txt
// Изменили существующий файл
echo "test" >> app.log
// Сохраняем всё в стэш
git stash push -u -m "Черновики логов и драфтов"
После этого:
draft.txtисчезнет из рабочего каталога (но будет в стэше);- изменения в
app.logтоже окажутся в стэше.
Опция -a или --all
Опция --all идёт ещё дальше — она включает:
- отслеживаемые файлы;
- неотслеживаемые файлы;
- игнорируемые файлы (те, что перечислены в
.gitignore).
Команда:
git stash save -a "Полная уборка рабочей директории"
Аналог:
git stash push -a -m "Полная уборка рабочей директории"
Будьте особенно внимательны с -a, если у вас есть полезные артефакты сборки или временные файлы, которые вы не хотели бы потерять из виду. Они тоже уйдут в стэш.
Практические сценарии использования git stash с сообщением
Сценарий 1 - Срочное переключение на багфикс
Представьте ситуацию:
- вы работаете над новой фичей в ветке
feature/checkout; - изменения ещё не готовы к коммиту;
- приходит запрос: «Нужно срочно поправить баг в проде».
Действия:
// Сохраняем все текущие изменения с понятным сообщением
git stash push -u -m "Незавершённая логика оформления заказа"
// Переключаемся на ветку с багфиксом
git checkout hotfix/payment-bug
// Работаем над багфиксом как обычно
// ...
// После завершения вернёмся к своей работе
git checkout feature/checkout
// Восстанавливаем изменения из стэша
git stash list
// Смотрим наш стэш по сообщению
git stash apply stash@{0} // или просто git stash apply, если он последний
Благодаря сообщению вы сразу понимаете, какой стэш относится к вашей задаче по оформлению заказа.
Сценарий 2 - Несколько параллельных задач в одной ветке
Иногда вы:
- начали одну задачу;
- пока работали, появилась вторая задача;
- ещё до конца первой задачи начали делать вторую.
В итоге у вас вперемешку изменения для разных задач. Здесь удобно разбить их на несколько стэшей с понятными сообщениями, а потом постепенно их применять.
Пример:
// Изменения по задаче A и по задаче B перемешаны в нескольких файлах
// Сначала часть правок по задаче B сохраняем в стэш с указанием файла
git stash push -m "Задача B - изменения в auth" auth/*
// Дорабатываем задачу A, коммитим её
git commit -am "Задача A - завершена"
// Теперь когда нужно вернуться к задаче B:
git stash list
git stash apply stash@{0} // по сообщению видим, что это нужный стэш
Сообщения помогают вам не перепутать, какие стэши относятся к какой задаче.
Сценарий 3 - Сохранение экспериментальных изменений
Иногда вы хотите попробовать что-то новое:
- переписать блок кода другим способом;
- протестировать новую библиотеку;
- сделать прототип.
Вы делаете экспериментальные правки, но не уверены, что будете их использовать. Вместо того, чтобы:
- захламлять историю временными коммитами;
- держать незавершённый код в рабочей директории;
проще спрятать эксперимент в стэш с пометкой «эксперимент»:
git stash push -m "Эксперимент с новой библиотекой логирования"
Если эксперимент окажется удачным:
git stash apply stash@{0}
Если нет — стэш можно просто удалить:
git stash drop stash@{0}
Как правильно читать и использовать stash list с сообщениями
Просмотр списка стэшей
Команда:
git stash list
Показывает список всех стэшей в формате:
stash@{0}: On feature/checkout: Незавершённая логика оформления заказа
stash@{1}: On develop: Эксперимент с новой библиотекой логирования
stash@{2}: On master: Временные правки конфига
Здесь:
stash@{0}— последний созданный стэш;stash@{1},stash@{2}— более старые;- сообщение после двоеточия — это то, что вы передали в
saveилиpush -m.
Чтобы ориентироваться в стэшах:
- используйте короткие, но содержательные сообщения;
- включайте в сообщение контекст задачи: «checkout», «auth», «payment» и т.д.;
- при большом числе стэшей периодически их чистите.
Как понять, что внутри конкретного стэша
Вы можете посмотреть, какие изменения есть в конкретном стэше:
git stash show stash@{0}
Эта команда отображает краткий дифф (изменённые файлы). Если вы хотите увидеть полный дифф:
git stash show -p stash@{0}
Комментарий:
// -p означает "patch" - вывести полный патч
// Здесь вы увидите строчки, которые были добавлены, изменены или удалены
Так вы можете быстро оценить, тот ли это стэш, который вам нужен, даже если сообщение не идеально точное.
Применение и восстановление стэшей с сообщениями
git stash apply против git stash pop
Есть два основных способа восстановить стэш:
git stash applygit stash pop
Разница:
apply— применяет изменения, но не удаляет стэш из списка;pop— применяет изменения и удаляет стэш.
Пример:
// Применить последний стэш
git stash apply
// Применить конкретный стэш
git stash apply stash@{2}
// Применить и удалить
git stash pop stash@{0}
Рекомендация:
- если вы не уверены, что стэш применится без конфликтов — используйте
apply; - если уверенны и стэш точно больше не нужен — можно сразу
pop.
Что делать, если при применении стэша возникли конфликты
Конфликты при apply или pop — обычное дело, особенно если с момента создания стэша ветка сильно изменилась.
Давайте посмотрим, что делать:
git stash apply stash@{0}
// Git сообщает о конфликтах
// Открываете файлы с конфликтами и вручную их исправляете
// После разрешения конфликтов добавляете файлы в индекс
git add путь/к/файлу
// При использовании apply сам стэш никуда не делся
// Если вы уверены, что он больше не нужен:
git stash drop stash@{0}
Если же вы использовали pop и возникли конфликты:
- стэш уже удалён;
- изменения физически применены в рабочем дереве;
- ваша задача — просто аккуратно разрешить конфликты и продолжить работу.
Работа с несколькими стэшами и их очистка
Удаление конкретного стэша - git stash drop
Если вы видите, что какой-то стэш больше не нужен (например, эксперимент не пригодился), его лучше удалить, чтобы не захламлять список:
git stash drop stash@{2}
Комментарии:
// Эта команда удалит только указанный стэш
// Нумерация других стэшей сдвинется
После этого stash@{3} может стать stash@{2}, и так далее.
Полная очистка стэшей - git stash clear
Если вы хотите удалить все стэши в репозитории:
git stash clear
Будьте внимательны: восстановить их потом будет уже нельзя. Используйте эту команду только если точно уверены, что ничего полезного больше в стэшах не осталось.
Отличия git stash save и git stash push в деталях
Сравнительная таблица возможностей
Давайте кратко сверим классический save и современный push:
git stash save "msg"- устаревающая форма;
- не позволяет явно указывать путь к файлам (только через сложные комбинации);
- поддерживает опции
-k,-u,-a, но интерфейс считается менее гибким.
git stash push -m "msg" [<path>...]- современная рекомендуемая форма;
- позволяет указывать конкретные файлы или директории;
- работает более предсказуемо в новых версиях Git;
- читабельнее, если смотреть на команду как на самостоятельную подкоманду
push.
Если вы только начинаете активно использовать стэши, лучше сразу привыкать к git stash push -m "сообщение" — в долгосрочной перспективе это удобнее.
Рекомендации по выбору сообщений для git stash save
Что писать в сообщении стэша
Сообщения стэшей лучше делать:
- краткими — не больше одной строки;
- содержательными — должно быть понятно, что именно вы спрятали;
- контекстными — хорошо, если вы явно упомянете модуль, задачу или проблему.
Примеры удачных сообщений:
Логика перерасчета скидки в корзинеЧерновик нового middleware для авторизацииЭксперимент с новым форматом конфигурацииПравки стилей для страницы профиля
Неудачные варианты:
123tmpwipqwe
Через несколько дней такие сообщения не дадут вам ни малейшего контекста.
Связь с задачами из трекера
Если вы используете трекер задач (Jira, YouTrack, Trello и т.д.), удобно указывать в сообщении ID задачи. Например:
PAY-312 Черновик расчета комиссииAUTH-57 Перепробовал альтернативный флоу логина
Так вы сможете быстро сопоставить стэш с задачей.
Нюансы и подводные камни при использовании git stash с сообщением
Нельзя использовать стэш как замену нормальной истории
Иногда разработчики начинают злоупотреблять стэшами:
- держат там большие долгоживущие изменения;
- не делают нормальные коммиты;
- используют стэш как «альтернативную историю» проекта.
Это рискованно:
- стэши локальны для репозитория и не попадают в удалённые репозитории (origin);
- при удалении или повреждении репозитория вы потеряете все стэши;
- в случае ошибок с
stash clearвсё исчезнет безвозвратно.
Правильный подход:
- использовать стэш как временный буфер на несколько часов или, максимум, дней;
- как только изменения обрели оформленный вид — переносить их в коммиты;
- удалять уже не нужные стэши.
Стэш и переключение веток
При переключении веток:
- Git может запретить переход, если есть незакоммиченные изменения, конфликтующие с целевой веткой;
стэш позволяет обойти это, но важно понимать, что:
- применять стэш лучше на той ветке, где он был создан;
- при применении стэша на другой ветке риск конфликтов выше.
Если всё же нужно применить стэш на другой ветке:
// На ветке A создали стэш
git stash push -m "Правки логики отправки email"
// Переключаемся на ветку B
git checkout B
// Применяем стэш здесь
git stash apply stash@{0}
Обратите внимание: в таком сценарии сообщения стэша особенно полезны — вы видите, какую именно логику вы переносите в другую ветку.
Итог
Использование git stash с осмысленными сообщениями — простой приём, который сильно упрощает повседневную работу с Git. Вместо безымянных WIP on branch вы получаете понятный журнал временных изменений, где по одному взгляду на git stash list становится ясно, какая запись за что отвечает.
Исторически для этого применяли команду git stash save "сообщение", но в современных версиях Git предпочтительнее использовать git stash push -m "сообщение" или сокращённую форму git stash -m "сообщение". При этом ключевые идеи остаются теми же:
- добавляйте сообщение при каждом сохранении стэша;
- используйте опции
-u,-a,--keep-indexв зависимости от того, что именно нужно спрятать; - не забывайте просматривать содержимое стэша через
git stash show -p, если не уверены, что в нём лежит; - применяйте
applyдля безопасного восстановления иpopдля восстановления с удалением.
Если вы будете использовать стэши как временный инструмент, а не как замену истории коммитов, и всегда снабжать их чёткими сообщениями, работа с незавершёнными изменениями станет гораздо более управляемой и предсказуемой.
Частозадаваемые технические вопросы по теме и ответы
Как изменить сообщение уже созданного стэша
Сообщение стэша напрямую изменить нельзя, но можно пересоздать стэш:
- Примените нужный стэш без удаления:
bash git stash apply stash@{2} - Создайте новый стэш с нужным сообщением:
bash git stash push -m "Новое сообщение" - Удалите старый стэш:
bash git stash drop stash@{2}
Как сохранить только часть изменений в файле в стэш
Git stash не умеет работать по частям файла напрямую, но можно использовать индекс:
- Добавьте в индекс только нужные куски:
bash git add -p путь/к/файлу// Здесь вы интерактивно выбираете участки кода - Сохраните в стэш только неиндексированные изменения:
bash git stash push -m "Стэш только неиндексированных изменений" --keep-index
Как застэшить изменения только в конкретной директории
Используйте git stash push с указанием пути:
git stash push -m "Фронтент изменения" frontend/
// В стэш попадут изменения только в каталоге frontend/
Как перенести стэш в другой клон репозитория
Стэши не передаются по push/pull. Обходной путь:
- Примените стэш в текущем репозитории:
bash git stash apply stash@{0} - Сделайте временный коммит:
bash git commit -am "Временный перенос изменений" - Сделайте push и в другом клоне выполните pull.
- В новом клоне при необходимости отмените коммит, но сохраните изменения в стэше:
bash git reset HEAD~1 git stash push -m "Импортированный стэш"
Почему git stash не сохраняет мои новые файлы
По умолчанию git stash save и git stash push не включают неотслеживаемые файлы. Чтобы новые файлы попали в стэш, используйте:
git stash push -u -m "Сохранить также новые файлы"
// Ключ -u добавит в стэш и untracked файлы, которые ещё не добавлены в индекс
Постройте личный план изучения Git до уровня Middle — бесплатно!
Git — часть карты развития Frontend
100+ шагов развития
30 бесплатных лекций
300 бонусных рублей на счет
Бесплатные лекции
Все гайды по Git
Лучшие курсы по теме

Основы Git
Антон Ларичев
TypeScript с нуля
Антон Ларичев