Применение сохранения в Git - git stash apply

17 декабря 2025

Автор

Олег Марков

Введение

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

Когда вы используете команду git stash, изменения в рабочем каталоге и индексе (staging area) убираются из текущего состояния ветки и сохраняются во внутреннем списке так называемых "сокрытий" (stash entries). Это позволяет вам:

переключиться на другую ветку;
обновить код из удалённого репозитория;
выполнить экспериментальные действия;
а затем вернуть изменения обратно.

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

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

Что такое сохранение (stash) в Git и зачем его применять

Прежде чем применять сохранения, важно чётко понимать, что именно вы применяете.

Как работает git stash в общем виде

Когда вы вызываете:

git stash
# или
git stash push

Git делает следующее:

Сохраняет текущие незакоммиченные изменения рабочего каталога.
Сохраняет состояние индекса (то, что уже было добавлено через git add).
Очищает рабочее дерево и индекс, возвращая их к состоянию последнего коммита.

В результате вы получаете "чистую" рабочую директорию, а ваши изменения попадают во внутренний список stash-объектов.

Посмотреть их можно так:

git stash list
# Пример вывода:
# stash@{0}: WIP on feature/login: 3a4b5c7 Добавлена базовая форма логина
# stash@{1}: WIP on main: 8d9e1f2 Обновление документации

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

Зачем использовать именно git stash apply

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

Основные сценарии, когда это полезно:

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

Важно подчеркнуть: git stash apply не удаляет применённое сохранение из списка. То есть оно остаётся доступным для повторного использования или анализа. Позже мы разберём, когда это удобно, а когда лучше использовать git stash pop.

Базовое использование git stash apply

Теперь давайте перейдём к самой команде применения сохранения и разберём её пошагово.

Применение последнего сохранения

Самый простой вариант:

git stash apply

Если не указывать никаких аргументов, Git возьмёт последнее сохранение из списка, то есть stash@{0}, и попытается применить его к текущему состоянию рабочей директории и индекса.

Что происходит внутри:

Git накладывает сохранённые изменения поверх текущего рабочего каталога.
Если часть изменений касается уже изменённых файлов, Git может создать конфликты.
Индекс восстанавливается не полностью: по умолчанию git stash apply не "восстанавливает" staged-состояние так же, как это было в момент сохранения, если вы не использовали особые опции при создании stash (об этом ниже).

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

Применение конкретного сохранения по индексу

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

git stash apply stash@{1}
# или
git stash apply stash@{2}

Сначала посмотрите список:

git stash list
# Здесь вы увидите нумерацию: stash@{0}, stash@{1}, ...

Затем примените нужное. Давайте разберём типичный сценарий:

# Сохранили работу над формой логина
git stash push -m "Форма логина - верстка"

# Сохранили работу над тестами
git stash push -m "Тесты для логина"

# Посмотрели, что есть
git stash list
# stash@{0}: On feature/login: Тесты для логина
# stash@{1}: On feature/login: Форма логина - верстка

# Сейчас вы хотите вернуть только верстку, без тестов
git stash apply stash@{1}

Как видите, вы можете выбрать любое сохранение, а не только последнее.

Как проверять результат применения

После применения stash полезно проверить статус:

git status
# Здесь вы увидите:
# - изменённые файлы
# - возможно, неотслеживаемые файлы, если они были сохранены с опцией include-untracked
# - наличие конфликтов (если произошли)

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

Отличия между git stash apply и git stash pop

Многие разработчики на первых порах путают эти команды. Давайте чётко разделим, что делает каждая.

Поведение git stash apply

Применяет выбранное сохранение к текущей рабочей директории.
Не удаляет сохранение из списка.
При конфликтах оставляет stash в списке, а в рабочей директории — конфликтные файлы.
Подходит, когда вы хотите:
- использовать одно и то же сохранение несколько раз;
- сначала убедиться, что оно применяется без конфликтов, а уже потом удалять его явно;
- использовать сохранение как "шаблон" изменений.

Поведение git stash pop

git stash pop
# или
git stash pop stash@{1}

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

Поэтому многие разработчики предпочитают безопасный подход:

Сначала использовать git stash apply.
Убедиться, что всё применилось корректно.
Явно удалить сохранение, которое больше не нужно:
```
git stash drop stash@{0}
# или удалить все:
git stash clear
```

Это даёт вам более контролируемый процесс и сводит к минимуму риск случайной потери изменений.

Примеры использования git stash apply в рабочих сценариях

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

Сценарий 1: Перенос изменений в другую ветку

Вы работаете в ветке main, вносите изменения, а затем понимаете, что всё это нужно было делать в ветке feature/new-api.

# Вы находитесь в main и что-то изменили
# Проверим статус
git status
# modified: api/server.go
# modified: api/routes.go

# Сохраняем изменения во временное сохранение
git stash push -m "Черновик нового API"
# Рабочая директория чистая

# Переключаемся в нужную ветку
git checkout feature/new-api

# Применяем сохранение
git stash apply
# Теперь изменения применены в ветке feature/new-api

Комментарий к примеру:

git stash push -m "Черновик нового API"
# Здесь мы создаём сохранение с понятным описанием, чтобы позже
# было проще найти нужный stash в списке

git checkout feature/new-api
# Переключаемся в ветку, куда на самом деле должны попасть изменения

git stash apply
# Применяем последнее сохранение в контексте новой ветки

Так вы мягко переносите изменения из одной ветки в другую без лишних коммитов и без копирования файлов вручную.

Сценарий 2: Временное отложение незавершённого функционала

Иногда приходится резко переключаться на срочную задачу.

# Работаете над большой фичей
git status
# modified: src/payment.cpp
# modified: src/payment.h

# Появляется срочный баг в проде, нужно срочно переключиться
git stash push -m "Незавершенный функционал оплаты"

# Переключаемся в ветку hotfix
git checkout hotfix/critical-bug

# Чиним баг, делаем коммит, пушим
# ...

# Возвращаемся к фиче
git checkout feature/payment-refactor

# Применяем сохранение
git stash apply stash@{0}

Если за время работы над багом вы создавали другие stash, возможно, нужное вам сохранение будет не stash@{0}. Поэтому лучше подстраховаться:

git stash list
# Найти по описанию "Незавершенный функционал оплаты"
git stash apply stash@{N}  # где N — нужный индекс

Сценарий 3: Повторное использование одного и того же сохранения

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

# Создаём сохранение с хелпером
git stash push -m "Вспомогательная функция для логирования"

# Переходим в ветку feature/a
git checkout feature/a
git stash apply stash@{0}
# Вносим доработки, коммитим

# Переходим в ветку feature/b
git checkout feature/b
git stash apply stash@{0}
# Снова используем те же изменения

# Когда больше не нужно, удаляем сохранение вручную
git stash drop stash@{0}

Здесь хорошо видно, почему git stash apply полезнее git stash pop — вы можете применять сохранение столько раз, сколько нужно, а удалять его только тогда, когда оно действительно перестаёт быть полезными.

Работа с индексом при git stash apply

Один из тонких моментов — как stash работает с индексом (staging area) и как это влияет на применение.

Что именно сохраняет git stash

По умолчанию при выполнении:

git stash push

Git сохраняет:

изменения в отслеживаемых файлах из рабочей директории;
состояние индекса — то, что вы уже добавили командой git add.

Однако поведение может отличаться, если вы используете флаги вроде --keep-index или --include-untracked. На это важно обратить внимание, так как при применении git stash apply вы можете получить не то, что ожидаете.

Опция --keep-index и её влияние

Команда:

git stash push --keep-index

делает следующее:

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

Пример:

# Изменили 2 файла
# file1.go и file2.go

git add file1.go
# file1.go — в индексе, file2.go — только в рабочей директории

git stash push --keep-index -m "Временное скрытие неготовых изменений"
# В stash попадут изменения из file2.go
# file1.go останется в индексе

При последующем применении:

git stash apply
# В рабочую директорию вернутся изменения только file2.go
# Индекс при этом не затронется

Здесь вы видите, что поведение индекса строго зависит от того, как было создано сохранение.

Восстановление staged-состояния

Некоторые разработчики ожидают, что git stash apply полностью вернёт и рабочие файлы, и staged-состояние (то, что уже было добавлено). Это частично правда, но всё зависит от сочетания опций, с которыми был создан исходный stash.

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

либо не использовать флаги вроде --keep-index без необходимости;
либо всегда проверять git status после применения и вручную восстанавливать staging (через git add), исходя из текущих задач.

Работа с неотслеживаемыми файлами и git stash apply

По умолчанию git stash не сохраняет неотслеживаемые файлы (untracked files). Это те файлы, которые ещё не были добавлены в репозиторий через git add.

Сохранение неотслеживаемых файлов

Чтобыstash включал и такие файлы, при создании используйте:

git stash push --include-untracked -m "Сохранение с неотслеживаемыми файлами"
# или сокращённо
git stash -u

В этом случае в stash попадут:

изменения отслеживаемых файлов;
новые файлы, ещё не добавленные в репозиторий.

Применение stash с неотслеживаемыми файлами

Когда вы затем выполняете:

git stash apply stash@{0}

Git попытается:

восстановить изменения отслеживаемых файлов;
создать/перезаписать неотслеживаемые файлы, которые были в stash.

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

Git может отказаться перезаписывать файлы и сообщит о конфликте;
или вам придётся вручную удалить/переименовать файлы, а затем повторить git stash apply.

Поэтому перед применением stash с неотслеживаемыми файлами полезно проверить:

git status
# Убедиться, что нет файлов, которые могут конфликтовать по имени

Что происходит при конфликтах при git stash apply

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

Когда возникают конфликты

Конфликты при применении stash возникают по тем же причинам, что и при обычном merge или rebase:

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

Давайте посмотрим пример:

# Вы сделали изменения в файле config.yml и создали stash
git stash push -m "Изменения конфигурации"

# Потом кто-то в команде изменил те же настройки и вы сделали git pull
git pull origin main

# Теперь вы пытаетесь применить сохранение
git stash apply
# Если изменения несовместимы, Git сообщит о конфликте

Как выглядят конфликты в файлах

Git добавит в конфликтные файлы знакомые разделители:

database:
<<<<<<< Updated upstream
  host: prod-db
  port: 5432
=======
  host: dev-db
  port: 5433
>>>>>>> Stashed changes

Комментарии:

<<<<<<< Updated upstream
# Этот блок показывает текущую версию из вашей ветки
=======
# Этот блок показывает изменения из stash, которые вы пытаетесь применить
>>>>>>> Stashed changes
# Ваша задача — вручную объединить оба варианта так, как нужно проекту

Как решать конфликты после git stash apply

Шаги обычно следующие:

Просмотреть статус:

git status
# Вы увидите файлы в состоянии both modified (оба изменены)

Открыть конфликтные файлы и вручную отредактировать содержимое, убрав разделители конфликтов.
Отметить конфликты как решённые:
```
git add path/to/file
```
Продолжить обычную работу: создать коммит, продолжить разработку, запустить тесты и т.д.

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

Отмена применения stash при конфликтах

Если вы применили stash, получили кучу конфликтов и решили, что проще откатиться, у вас есть варианты:

Вернуть рабочую директорию к последнему коммиту:
```
git reset --hard HEAD
```
Но будьте осторожны — это удалит все текущие незакоммиченные изменения.
Если вы не хотите так резко очищать всё, можно вручную удалить/откатить только конфликтные файлы, а затем снова попробовать применить stash в более подходящий момент или ветке.

Просмотр содержимого stash перед применением

Часто перед применением сохранения полезно посмотреть, что в нём находится, чтобы не получить сюрпризов.

Краткий просмотр списка

git stash list
# Пример:
# stash@{0}: On feature/profile: Исправления аватаров
# stash@{1}: On main: Черновик нового API

Здесь вы видите:

индекс stash;
ветку, на которой он был создан;
комментарий (если вы его указали).

Просмотр разницы одного stash

Чтобы посмотреть, какие изменения содержит конкретный stash, используйте:

git stash show stash@{0}
# Показывает сводку изменений (какие файлы и в каком объёме изменились)

Если вы хотите увидеть детальный diff:

git stash show -p stash@{0}
# -p (или --patch) показывает построчные изменения

Пример:

git stash show -p stash@{0}
# Здесь вы увидите обычный diff между базовым коммитом
# и изменениями, сохранёнными в этом stash

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

Безопасные практики работы с git stash apply

Чтобы использование git stash apply не приводило к потере времени и нервов, полезно придерживаться нескольких правил.

Всегда комментируйте сохранения

Вместо безымянных stash:

git stash

лучше использовать:

git stash push -m "Рефакторинг сервиса оплаты - подготовка к выделению интерфейса"

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

Предпочитайте git stash apply перед git stash pop

Типичная безопасная схема:

Создаёте сохранение (с понятным описанием).
Перед применением убеждаетесь, что ветка и состояние проекта подходят для этих изменений.
Используете git stash apply.
Проверяете результат, решаете конфликты.
Если изменения больше не нужны в виде stash — удаляете его вручную через git stash drop.

Так вы избегаете ситуации, когда stash внезапно исчезает после неудачного pop.

Регулярно чистите ненужные сохранения

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

Рекомендуемые действия:

После успешного применения и коммита изменений:
```
git stash drop stash@{N}
```
Периодически удаляйте все устаревшие сохранения (если вы точно уверены, что они больше не нужны):
```
git stash clear
```

Думайте о совместимости веток

Перед тем как применять stash в другой ветке, задайте себе вопросы:

Сильно ли отличается код в этой ветке от той, где создавался stash?
Не были ли удалены/переименованы файлы, к которым относятся изменения?
Есть ли шанс, что изменения логически не подходят к текущей ветке?

Если сомнения есть, возможно, лучше:

применить stash в исходной ветке;
сделать нормальный коммит;
а затем использовать git cherry-pick или merge для переноса изменений.

Заключение

git stash apply — это удобный и достаточно безопасный инструмент для работы с временными изменениями в Git. Он помогает:

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

Главные особенности, о которых важно помнить:

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

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

Частозадаваемые технические вопросы по теме

Как применить stash только к одному файлу

Иногда нужно вернуть изменения только для одного файла из сохранения.

Узнайте хеш коммита stash:

git stash list
# запомните индекс, например stash@{0}

git stash show -p stash@{0}  # убедитесь, что там есть нужный файл

Вытяните изменения только по одному файлу:

git checkout stash@{0} -- path/to/file
# Здесь мы берем версию файла из stash и кладем её в рабочую директорию

Проверьте результат через git status и при необходимости добавьте файл в индекс.

Что делать, если git stash apply пишет, что рабочая директория не чистая

Если у вас уже есть незакоммиченные изменения, git stash apply может отказать или создать сложные конфликты.

Посмотрите текущие изменения:
```
git status
```
Примите решение:
- либо закоммитить текущие изменения;
- либо временно сохранить их в отдельный stash:
```
git stash push -m "Временное сохранение перед применением другого stash"
```
Затем повторите git stash apply для нужного сохранения.

Как откатить результат git stash apply, если я передумал

Если после применения stash вы решили, что изменения не нужны:

Если вы ещё ничего не добавляли и не коммитили, можно откатиться к HEAD:
```
git reset --hard HEAD
```
Если вы уже частично правили файлы, используйте:
```
git restore path/to/file
# или для всех файлов
git restore .
```
Это вернёт файлы к состоянию последнего коммита.

Можно ли применить stash в совершенно другом репозитории

Напрямую — нет. Stash привязан к конкретному репозиторию. Но вы можете:

Создать ветку из stash:

git stash branch temp-from-stash stash@{0}

Сделать в этой ветке коммит с нужными изменениями.
Затем перенести его в другой репозиторий с помощью git format-patch и git am, либо через обычный патч git diff > patchfile и git apply patchfile.

Почему после git stash apply некоторые файлы не вернулись

Причины могут быть такими:

При создании stash не использовалась опция --include-untracked, поэтому новые файлы не попали в сохранение.
Файлы были удалены или переименованы в текущей ветке, и Git не смог корректно применить изменения.
Были конфликты, и Git не смог автоматически восстановить часть изменений.

Как действовать:

Посмотрите содержимое stash:
```
git stash show -p stash@{N}
```
Если нужный файл там есть, восстановите его отдельно:
```
git checkout stash@{N} -- path/to/file
```
Проверьте результат и при необходимости добавьте файл в индекс перед коммитом.