Git Stash vs Shelve in IntelliJ IDEA

Use shelving when you want to set aside selected files or a change list as IntelliJ IDEA-managed saved changes. Use git stash when you want Git to save working-tree changes as Git-managed data that you can access with Git commands or other Git clients. Both help you switch tasks and return later, but the saved work is managed by different systems. A shelf is an IntelliJ IDEA feature; a stash is not an ordinary commit in project history, and a shelf is not a general substitute when you need Git-level portability.

Shelving is useful when only part of your current work should be set aside. Git stash is a better fit when you want the saved work available through Git commands or another client. Neither choice commits your work. Menu wording and locations can vary between IntelliJ IDEA versions and UI languages, so use the labels below as recognizable names rather than assuming every installation lays them out identically. IntelliJ IDEA provides shelving through its Shelve Changes action; git shelve is not a Git command.

Shelve Changes in Git

In IntelliJ IDEA, shelving saves selected changes for later without creating a commit. You can shelve individual files or a whole change list, give the shelf a descriptive name, and apply a shelf more than once if you need its changes again. This makes shelving a useful way to park one task while leaving unrelated work in the working copy.

1. Open the Commit tool window and select the files or change list to set aside.
2. Open the context menu and choose Shelve Changes.
3. Review the selection, enter a useful name in the Commit Message field, and choose Shelve Changes to save it.

The Commit tool’s Shelve Silently action shelves the selected changes without opening the review dialog. Use it when the selection is already clear; otherwise, review the files and name before saving.

Unshelve Changes in Git

To restore a shelf, open the Shelf tab, select the shelved files or change list, and choose Unshelve. In the dialog, choose an existing destination change list or create a new one, then confirm. If you create a list, mark it Active when you want IntelliJ IDEA to make it the current list. The active-list step is about where subsequent IDE changes are grouped; it is not required to restore into a list that is already active.

You can also use Unshelve Silently to move selected shelved changes into the active change list without the dialog. Check that the intended list is active first. Unshelving reapplies the saved changes to the working copy, so review the result if other edits have changed the same files in the meantime.

Stash Changes in Git

A Git stash records changes relative to HEAD. By default, git stash saves changes to tracked files, including staged and unstaged edits, and restores the tracked files to their committed state. It does not include untracked files by default; Git’s -u option includes untracked files, while -a also includes ignored files. Choose deliberately when using a graphical dialog, since the available controls and labels can differ.

In IntelliJ IDEA, open Git > Uncommitted Changes > Stash Changes. Select the repository directory and branch shown for the operation, add a short description in Message, and choose Create Stash. Confirm the intended repository and branch before saving, especially if the IDE has multiple repositories open. A descriptive message makes the entry easier to identify later.

Shelving and stashing have different selection models: IntelliJ IDEA shelving lets you select files or a change list directly, while Git stash works on tracked changes by default and has options for untracked or ignored files. Both can be reapplied, but the saved item belongs to a different system and should be restored with its matching workflow.

Apply a Stash in Git

To inspect or restore a stash in IntelliJ IDEA, open Git > Uncommitted Changes > Unstash Changes, then choose the repository and branch. Select a stash and choose View to inspect the files and changes it would apply. Use Apply Stash to restore the changes while keeping the stash entry, or Pop Stash to apply it and remove the entry after a successful application. If conflicts prevent a pop from completing, keep and resolve the stash before removing it.

The dialog’s As new branch option applies the stash on a new branch named in that field. This is useful when the saved work should become a separate line of development. Applying a stash can produce conflicts if the current files differ from the saved base. A clean working tree is the safest starting point, but a dirty tree is not categorically prohibited: whether Git can apply the stash depends on whether the changes can be combined without overwriting local work. Review the diff and resolve any conflicts before continuing.