Sta sh что это

7.3 Инструменты Git — Припрятывание и очистка

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

Операция stash берет изменённое состояние вашего рабочего каталога, то есть изменённые отслеживаемые файлы и проиндексированные изменения, и сохраняет их в хранилище незавершённых изменений, которые вы можете в любое время применить обратно.

Примечание
Переход на git stash push

В конце октября 2017 года в списке рассылки Git проходило обширное обсуждение, по итогам которого команда git stash save признана устаревшей в пользу существующей альтернативы git stash push . Основная причина этого заключается в том, что в git stash push есть возможность сохранить выбранные спецификации пути, что не поддерживает git stash save .

Команда git stash save не исчезнет в ближайшее время, поэтому не беспокойтесь о её внезапной пропаже. Но вы можете начать переход на push для использования новой функциональности.

Припрятывание ваших наработок

Для примера, предположим, что вы перешли в свой проект, начали работать над несколькими файлами и, возможно, добавили в индекс изменения одного из них. Если вы выполните git status , то увидите ваше изменённое состояние:

$ git status Changes to be committed: (use "git reset HEAD . " to unstage) modified: index.html Changes not staged for commit: (use "git add . " to update what will be committed) (use "git checkout -- . " to discard changes in working directory) modified: lib/simplegit.rb

Теперь вы хотите сменить ветку, но пока не хотите фиксировать ваши текущие наработки; поэтому вы припрячете эти изменения. Для того, чтобы припрятать изменение в выделенное для этого специальное хранилище, выполните git stash или git stash push :

$ git stash Saved working directory and index state \ "WIP on master: 049d078 Create index file" HEAD is now at 049d078 Create index file (To restore them type "git stash apply")

Теперь вы можете увидеть, что рабочая копия не содержит изменений:

$ git status # On branch master nothing to commit, working directory clean

В данный момент вы можете легко переключать ветки и работать в любой; ваши изменения сохранены. Чтобы посмотреть список припрятанных изменений, вы можете использовать git stash list :

$ git stash list stash@: WIP on master: 049d078 Create index file stash@: WIP on master: c264051 Revert "Add file_size" stash@: WIP on master: 21d80a5 Add number to log

В данном примере, предварительно были припрятаны два изменения, поэтому теперь вам доступны три различных отложенных наработки. Вы можете применить только что припрятанные изменения, используя команду, указанную в выводе исходной команды: git stash apply . Если вы хотите применить одно из предыдущих припрятанных изменений, вы можете сделать это, используя его имя, вот так: git stash apply stash@ . Если вы не укажете имя, то Git попытается восстановить самое последнее припрятанное изменение:

$ git stash apply On branch master Changes not staged for commit: (use "git add . " to update what will be committed) (use "git checkout -- . " to discard changes in working directory) modified: index.html modified: lib/simplegit.rb no changes added to commit (use "git add" and/or "git commit -a")

Как видите, Git восстановил в файлах изменения, которые вы отменили ранее, когда прятали свои наработки. В данном случае при применении отложенных наработок ваш рабочий каталог был без изменений, а вы пытались применить их в той же ветке, в которой вы их и сохранили; но отсутствие изменений в рабочем каталоге и применение их в той же ветке не являются необходимыми условиями для успешного восстановления припрятанных наработок. Вы можете припрятать изменения, находясь в одной ветке, а затем переключиться на другую и попробовать восстановить эти изменения. Также при восстановлении припрятанных наработок в вашем рабочем каталоге могут присутствовать изменённые и незафиксированные файлы — Git выдаст конфликты слияния, если не сможет восстановить какие-то наработки.

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

$ git stash apply --index On branch master Changes to be committed: (use "git reset HEAD . " to unstage) modified: index.html Changes not staged for commit: (use "git add . " to update what will be committed) (use "git checkout -- . " to discard changes in working directory) modified: lib/simplegit.rb

Команда apply только пытается восстановить припрятанные наработки — при этом они останутся в хранилище. Для того, чтобы удалить их, вы можете выполнить git stash drop , указав имя удаляемых изменений:

$ git stash list stash@: WIP on master: 049d078 Create index file stash@: WIP on master: c264051 Revert "Add file_size" stash@: WIP on master: 21d80a5 Add number to log $ git stash drop stash@ Dropped stash@ (364e91f3f268f0900bc3ee613f9f733e82aaed43)

Вы также можете выполнить git stash pop , чтобы применить припрятанные изменения и тут же удалить их из хранилища.

Необычное припрятывание

У припрятанных изменений есть несколько дополнительных вариантов использования, которые также могут быть полезны. Первый — это использование довольно популярной опции —keep-index с командой git stash . Она просит Git не только припрятать то, что вы уже добавили в индекс, но одновременно оставить это в индексе.

$ git status -s M index.html M lib/simplegit.rb $ git stash --keep-index Saved working directory and index state WIP on master: 1b65b17 added the index file HEAD is now at 1b65b17 added the index file $ git status -s M index.html

Другой распространённый вариант, который вы, возможно, захотите использовать — это припрятать помимо отслеживаемых файлов также и неотслеживаемые. По умолчанию git stash будет сохранять только изменённые и проиндексированные отслеживаемые файлы. Если вы укажете опцию —include-untracked или -u , Git также припрячет все неотслеживаемые файлы, которые вы создали. Однако включение этой опции по-прежнему не будет прятать файлы с явным игнорированием; чтобы дополнительно припрятать игнорируемые файлы, используйте —all (или просто -a ).

$ git status -s M index.html M lib/simplegit.rb ?? new-file.txt $ git stash -u Saved working directory and index state WIP on master: 1b65b17 added the index file HEAD is now at 1b65b17 added the index file $ git status -s $

И наконец, если вы укажете флаг —patch , Git не будет ничего прятать, а вместо этого в интерактивном режиме спросит вас о том, какие из изменений вы хотите припрятать, а какие оставить в вашем рабочем каталоге.

$ git stash --patch diff --git a/lib/simplegit.rb b/lib/simplegit.rb index 66d332e..8bb5674 100644 --- a/lib/simplegit.rb +++ b/lib/simplegit.rb @@ -16,6 +16,10 @@ class SimpleGit return `# 2>&1`.chomp end end + + def show(treeish = 'master') + command("git show #") + end end test Stash this hunk [y,n,q,a,d,/,e,?]? y Saved working directory and index state WIP on master: 1b65b17 added the index file

Создание ветки из припрятанных изменений

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

$ git stash branch testchanges M index.html M lib/simplegit.rb Switched to a new branch 'testchanges' On branch testchanges Changes to be committed: (use "git reset HEAD . " to unstage) modified: index.html Changes not staged for commit: (use "git add . " to update what will be committed) (use "git checkout -- . " to discard changes in working directory) modified: lib/simplegit.rb Dropped refs/stash@ (29d385a81d163dfd45a452a2ce816487a6b8b014)

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

Очистка рабочего каталога

Наконец, у вас может возникнуть желание не прятать некоторые из изменений или файлов в вашем рабочем каталоге, а просто избавиться от них. Команда git clean сделает это для вас.

Одной из распространённых причин для этого может быть удаление мусора, который был сгенерирован при слиянии или внешними утилитами, или удаление артефактов сборки в процессе её очистки.

Вам нужно быть очень аккуратными с этой командой, так как она предназначена для удаления неотслеживаемых файлов из вашего рабочего каталога. Даже если вы передумаете, очень часто нельзя восстановить содержимое таких файлов. Более безопасным вариантом является использование команды git stash —all для удаления всего, но с сохранением этого в виде припрятанных изменений.

Предположим, вы хотите удалить мусор и очистить ваш рабочий каталог; вы можете сделать это с помощью git clean . Для удаления всех неотслеживаемых файлов в вашем рабочем каталоге, вы можете выполнить команду git clean -f -d , которая удалит все файлы и также все каталоги, которые в результате станут пустыми. Параметр -f (сокращение от слова force — заставить) означает принудительное удаление, подчеркивая, что вы действительно хотите это сделать, и требуется, если переменная конфигурации Git clean.requireForce явным образом не установлена в false .

Если вы хотите только посмотреть, что будет сделано, вы можете запустить команду с опцией -n , которая означает «имитируй работу команды и скажи мне, что ты будешь удалять».

$ git clean -d -n Would remove test.o Would remove tmp/

По умолчанию команда git clean будет удалять только неотслеживаемые файлы, которые не добавлены в список игнорируемых. Любой файл, который соответствует шаблону в вашем .gitignore , или другие игнорируемые файлы не будут удалены. Если вы хотите удалить и эти файлы (например, удалить все .o -файлы, генерируемые в процессе сборки, и таким образом полностью очистить сборку), вы можете передать команде очистки опцию -x .

$ git status -s M lib/simplegit.rb ?? build.TMP ?? tmp/ $ git clean -n -d Would remove build.TMP Would remove tmp/ $ git clean -n -d -x Would remove build.TMP Would remove test.o Would remove tmp/

Если вы не знаете, что сделает при запуске команда git clean , всегда сначала выполняйте её с опцией -n , чтобы проверить дважды, перед заменой -n на -f и выполнением настоящей очистки. Другой способ, который позволяет вам более тщательно контролировать сам процесс — это выполнение команды с опцией -i (в «интерактивном» режиме).

Ниже выполнена команда очистки в интерактивном режиме.

$ git clean -x -i Would remove the following items: build.TMP test.o *** Commands *** 1: clean 2: filter by pattern 3: select by numbers 4: ask each 5: quit 6: help What now>

Таким образом, вы можете просмотреть каждый файл индивидуально или указать шаблоны для удаления в интерактивном режиме.

Примечание

Существует причудливая ситуация, когда вам, возможно, придется проявить особую настойчивость, попросив Git очистить ваш рабочий каталог. Если вы оказались в рабочем каталоге, в который вы скопировали или клонировали другие репозитории Git (возможно, в виде подмодулей), даже git clean -fd откажется удалить эти каталоги. В таких случаях вам нужно добавить второй параметр -f для акцентирования.

Руководство по git stash

Инструкция о том, как откладывать изменения, сделанные в рабочей копии, чтобы можно было применить их позже.

Эта инструкция — часть курса «Введение в Git».

Смотреть весь курс

Введение

В процессе написания кода может возникнуть ситуация, когда нужно срочно переключиться на другую ветку (использовать git checkout) — или, например, внести правки, которые относятся к другой задаче. Однако новые изменения еще не готовы к тому, чтобы их коммитить и добавлять в репозиторий, — при этом терять их нельзя. В таком случае, как и во многих других, полезной окажется команда git stash.

Откладывание кода

Git stash

git stash

Git stash перемещает текущие изменения (так называемые local changes) в локальную директорию, которая выполняет роль специального хранилища, то есть скрывает эти изменения, сохраняя их отдельно, с опцией вернуть позже, когда это понадобится. Таким образом, файлы рабочей копии возвращаются к своему исходному состоянию. Внесенные изменения помещаются в стек, после чего их можно легко оттуда извлечь. Важно отметить, что в рабочей копии исчезнут все измененные файлы, — независимо от того, добавлены они в индекс или нет.

После выполнения этой строки все несохраненные изменения будут сохранены, но не закоммичены. Эти отложенные участки будут сохранены в локальном репозитории и при выполнении команды git push не будут переданы на сервер. Такие изменения иногда называют «прятанья».

Git stash save

Команда git stash save исполняет ту же функцию, но имеет другие опции.

Git stash save

Когда необходимо добавить комментарий, мы прописываем его вместе с основной командой:

git stash save ""

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

git stash save --include-untracked

git stash save -u

Git stash push

Сейчас команда git stash save считается неактуальной, ее более полезная замена — git stash push. Вызвано это прежде всего тем, что, выполняя git stash push, можно сохранять определенные спецификации пути. Это, к сожалению, не поддерживается git stash save. Git stash save все еще работает, но в будущем следует ожидать постепенного перехода на git stash push из-за доступности нового функционала.

Применение отложенных изменений

Теперь мы знаем, как «спрятать» ненужные в текущий момент изменения, но не знаем, как их извлечь и вернуть в рабочую версию проекта (или, еще можно сказать, сделать «git unstash»). Для решения такой проблемы понадобится git stash pop:

git stash pop

После выполнения в хранилище очищаются изменения и возвращаются к рабочей копии. Если же необходимо, чтобы изменения остались (то есть не удалились из хранилища), но при этом вернулись в проект, мы применим git stash apply:

git stash apply

Этим полезно пользоваться, когда одни и те же части кода нужны для корректной работы нескольких веток — или в том случае, если необходимо удалить ветку, в которой изначально были сделаны эти изменения. Тогда можно автоматически перенести желаемые участки кода.

git branch --delete

Необычное откладывание

Еще одну вариацию использования git stash составляет флаг —keep-index:

git stash --keep-index

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

Откладывание неотслеживаемых или игнорируемых файлов

При работе с git stash нельзя забывать, что простое выполнение этой команды не дает скрывать изменения в некоторых типах файлов, то есть не убирает в хранилище появившиеся правки кода. К таким типам относятся неотслеживаемые и игнорируемые.

Все «прятанья», создаваемые git stash, делятся на две категории: индексированные и неиндексированные. Индексированными называются исправления, которые уже были добавлены в раздел проиндексированных файлов, а неиндексированными — исправления, которые отслеживаются сейчас.

Проиндексированными называются файлы, о чьих преобразованиях уже знает Git, но само изменение еще не записано в репозиторий.

Поэтому логично, что новые файлы не смогут быть отложены, если они все еще не проиндексированы. Точно так же, как и игнорируемые (помеченные явным образом как файлы, которые необходимо игнорировать).

При необходимости спрятать неотслеживаемые файлы поможет уже известный параметр -u (или же -include-untracked):

git stash -u

Перенос правок для игнорируемых файлов осуществляется с помощью флага -all:

git stash -all

git stash -a

Управление несколькими наборами отложенных изменений

При повторном использовании git stash мы можем понять, что фактически мы создаем коммит, но сохраняем его по отдельности. Используя следующее выражение, мы можем посмотреть на список всех спрятанных изменений:

git stash list

Полученный список будет отсортирован по времени, когда были отложены изменения: внизу списка будут самые старые изменения. Также каждое изменение имеет свой идентификатор с номером, например:

stash@: WIP on master: 08f13aa add processing file stash@: WIP on master: c33b610 refactor code 

Описание «прятаний» по умолчанию начинается с WIP (что указывает на незавершенную работу) перед названием ветки (в частности коммита), где их отложили.

После выполнения git stash pop будет возвращен последний из наборов откладываний (с индексом 0). Если нужно выбрать конкретный набор из всех ранее отложенных участков, то в фигурных скобках нужно явно прописать его идентификатор. Например:

git stash pop stash@

Просмотр различий между наборами отложенных изменений

Команда git stash show выводит информацию по последнему сделанному изменению:

git stash show

Если нужно посмотреть информацию о другом изменении, то необходимо явно указать индекс:

git stash show stash@

Очень полезной функцией может стать сравнение полученных наборов друг с другом. Для такой ситуации понадобится параметр —patch:

git stash show --patch

Или что будет равносильно:

git stash show -p

Частичное откладывание изменений

Иногда бывает удобно разделить существующие в коде незакоммиченные изменения на несколько откладываний. Тогда в разных откладываниях могут храниться изменения в разных файлах или даже в одном. Тогда необходимо написать флаг -p (или —patch):

git stash -p

Теперь откладывание для каждого из участков будет выполняться отдельно, при этом запрашивая подтверждение:

• ? — узнать все возможные варианты для работы (ниже будут перечислены самые распространенные);
• y — отложить этот участок;
• / — использовать для поиска регулярное выражение;
• n — не откладывать этот участок кода;
• q — отложить все выбранные участки и выйти;
• s — разделить текущее изменение на несколько откладываний.

Прервать работу откладывания поможет комбинация клавиш CTRL+C.

Создание ветки из отложенных изменений

При работе с разными ветками и откладыванием изменений (или другими операциями) могут возникнуть конфликты. Одной из возможностью избежать этого и ничего не сломать будет создание новой ветки и применение изменений в ней:

git stash branch

Теперь будет создана новая ветка, к которой уже применятся сделанные изменения. Однако последние правки будут удалены из списка всех спрятанных изменений. Как и в предыдущих случаях, если нужно работать не с последним набором, то можно указать индекс.

Удаление отложенных изменений

Теперь нам нужно научиться удалять отложенные изменения:

git stash drop

Так мы удалим последний набор. Аналогично другим командам для удаления определенного набора указываем индекс:

git stash drop stash@

Иногда нужно очищать хранилище от всех наборов, то есть отменять все созданные изменения. В таких случаях мы пишем:

git stash clear

Разрешение конфликтов

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

Чтобы посмотреть файлы, в которых возникли конфликты, нужно воспользоваться git status. Они будут находиться в секции Unmerged paths. Также все новые изменения отслеживаемых и проиндексированных файлов будут находиться в разделе Changes to be committed.

Разрешить такой конфликт необходимо вручную. Однако в отличие от конфликтов, например, при слиянии веток (выполнение git merge), нет потребности сразу коммитить изменения, так как код еще не закончен и не готов для полноценного коммита. А после этого можно добавить его в индекс и сделать привычный коммит.

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

Принцип работы команды git stash

Разберемся, как устроена работа команды и получим более подробное git stash-описание.

Мы уже знаем, что наборы откладываний на самом деле являются коммитами (из этого следует, что команда git log корректно отработает, выводя изменения). Ссылка в .git/refs/stash ведет на последнюю группу откладываний. Чтобы найти более ранние наборы, существует журнал ссылок, который так и называется — stash. Поэтому если нужно просмотреть «прятанья», мы пишем stash@, то есть обращаемся к записи с номером n.

В зависимости от откладываемых элементов git stash создает от двух до трех коммитов. Конкретно рассмотрим, какие это будут коммиты.

• В коммите stash@ будут содержаться файлы в исходном коде на момент запуска команды.
• Первым предком stash@ будет являться уже существующий коммит в той ветке, куда ведет HEAD.
• Второй предок stash@ — новый коммит, который является индексом.
• Третий коммит будет создан только в том случае, если в проекте содержатся неотслеживаемые Git-файлы или были указаны параметры -u или -a. Это будет коммит с файлами, которые содержатся в исходном коде и не видны Git’у.

Теперь поподробнее разберем, как git stash зашифровывает рабочий каталог и работает с проиндексированными файлами.

• Выше мы разбирали, что каталог может содержать исправления в разных типах файлов. Такие файлы могут быть только частично отмечены в репозитории.
• Git stash кодирует преобразования в отслеживаемых участках под видом ориентированного ациклического графа (это можно проверить, если нарисовать дерево, описанное выше). Целью одного коммита будет хранение неиндексированных, а второго — уже индексированных изменений, которые были отмечены как проиндексированные файлы.
• Помним, что флаг -u зашифровывает все правки неотслеживаемых файлов в виде другого коммита, в то время как параметр -a, наоборот, включает изменения в игнорируемых файлах в тот же (не создавая при этом дополнительный коммит).

Осталось разобраться, что происходит, когда мы реализуем git stash pop. Спрятанные части кода из всех перечисленных выше пунктов возвращаются сразу и в рабочую копию, и, что важно, также к разделу проиндексированных файлов Git. После этого коммит, который мы извлекли, будет удален из stash. Остальные ссылки в журнале просто сдвигаются (чтобы обеспечить далее корректную работу). Коммиты, которые мы извлекли, не очищаются сразу, но отмечаются как мусор и впоследствии удаляются.

Заключение

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

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

Что такое GitLab, как и для чего он используется

Stash — Введение в Git

Представьте себе ситуацию. Вы работаете над какой-то важной задачей и исправили довольно много файлов. В этот момент появляется срочная задача — сделать какое-то изменение в исходном коде, не связанное с тем, над чем вы сейчас работаете. Ваши изменения еще не готовы, и они не должны попасть в репозиторий. Что делать? В этом уроке мы разберем команду, которая поможет в этом случае.

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

Подобная ситуация у опытных разработчиков встречается регулярно. К счастью, она легко решается. В Git существует набор команд, позволяющий прятать изменения в рабочей директории и восстанавливать их при необходимости. Попробуем:

touch FILE.md git add FILE.md git status On branch main Your branch is up to date with 'origin/main'. Changes to be committed: (use "git restore --staged . " to unstage) new file: FILE.md # Прячем файлы # После этой команды пропадут все измененные файлы # независимо от того, добавлены они в индекс или нет git stash Saved working directory and index state WIP on main: e7bb5e5 update README.md git status On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean 

Команда git stash не удаляет файлы. Они попадают в специальное место внутри директории .git на временное хранение. Эта команда не трогает новые файлы, так как они еще не являются частью репозитория:

После выполнения всех нужных изменений в чистой рабочей директории можно вернуть спрятанные изменения с помощью команды git stash pop :

# Восстанавливаем git stash pop On branch main Your branch is up to date with 'origin/main'. Changes to be committed: (use "git restore --staged . " to unstage) new file: FILE.md Dropped refs/stash@0> (b896d4a0126ef4409ede63857e5d996953fe75c5) # Проверяем git status On branch main Your branch is up to date with 'origin/main'. Changes to be committed: (use "git restore --staged . " to unstage) new file: FILE.md 

Файлы вернулись в том виде, в котором они попали в стэш (stash).

Стэш в Git работает по принципу стека . Он позволяет сохранить внутрь любое количество изменений и восстановить их в обратном порядке:

# Изменяем файлы git stash # Возвращаем последние изменения git stash pop # Возвращаем предпоследние изменения git stash pop 

Дополнительные материалы

1. Припрятывание (Stash) и очистка
2. Псевдонимы (алиасы) команд в Git

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты

Git Stash

Команда git stash предназначена для того, чтобы поместить текущие изменения в отдельное хранилище и вернуть файлы к исходному состоянию. То есть git stash прячет изменения в файлах и сохраняет эти изменения отдельно, чтобы потом можно было их вернуть.

Сохранение изменений

git stash save "description of stash"

… создать stash с человекопонятным описанием этого stash — чтобы можно было через день, глядя на него, догадаться вообще, что это такое и зачем оно делалось.

git stash -u save "description of stash"

… создать stash с изменениями, которые еще unstaged. Иначе они просто не попадут в снимок stash.

git stash branch newAwesomeBranch

… создание новой ветки из stash@ . Важный момент — чтобы изменения попали с новую ветку, они должны сначала быть помещены в stash@ .

git stash branch newAwesomeBranch stash@1>

… поместить изменения из конктерного stash@ в новую ветку newAwesomeBranch.

git stash -p

git stash show

git stash show stash@1>

git stash show -p stash@1>

git stash list

git stash drop stash@1>

git stash drop

git stash clear

git stash apply

git stash apply stash@2>

git stash pop

git stash pop stash@2>