Git Fundamentals
Stashing Changes — git stash
Git stash is a powerful utility that temporarily shelves your uncommitted changes, allowing you to switch contexts without the overhead of creating a premature commit. It matters because it protects your workflow when you need to perform an urgent task or pull upstream changes without disrupting your current experimentation. You reach for it whenever your working directory is cluttered with unfinished work, but you need to return to a clean state immediately.
The Core Concept of the Stash Stack
To understand why git stash works, you must recognize that Git operates on a snapshot-based model. When you modify files, those changes exist in your working directory and the staging area, separate from the commit history. The stash mechanism functions as a specialized stack—a last-in, first-out (LIFO) data structure. When you run the stash command, Git takes the differences between your HEAD commit and your current working directory, creates a temporary commit object internally, and stores it in a hidden reference. Because it is a stack, you can stash multiple times, and each subsequent stash is indexed as 'stash@{n}', where zero represents the most recent action. This is essentially a way to move messy, non-ready work out of the way into a temporary storage location, effectively 'cleaning' your working directory so you can perform other operations like checking out different branches or pulling fresh data from remote servers without triggering merge conflicts that would arise from your currently uncommitted local modifications.
# Save current changes to the stash stack
# The name 'WIP' is optional but helps with organization
git stash push -m "Working on user authentication logic"
# List all stored stashes to verify index positions
git stash listRetrieving Stashed Work with Apply versus Pop
Once your urgent tasks are completed and you are ready to return to your previous progress, you must move your changes from the hidden stack back into your working directory. Git provides two primary ways to do this: applying and popping. When you apply a stash, Git attempts to re-create the modifications at the file system level; if the file structure has changed significantly since you stashed, this can lead to conflicts. Popping is the preferred method for most users because it applies the changes and immediately removes that specific entry from the stack. The reasoning behind using 'pop' is to keep the stash stack uncluttered, preventing you from accidentally re-applying stale work later. Think of the stash stack as a scratchpad; once the information is copied onto the workspace, the page on the scratchpad is no longer needed. This workflow ensures that your primary repository remains clean while your transient thoughts and temporary code snippets remain safely archived but accessible.
# Apply the most recent stash and remove it from the stack
git stash pop
# Alternatively, apply without removing if you want to keep a backup
git stash apply stash@{0}Handling Untracked Files
A common point of confusion for beginners is that standard stashing only saves tracked files. If you have created a new configuration file or a temporary utility script that has not yet been added to the staging area with the git add command, Git will ignore it by default when you run a standard stash command. To capture these files, you must explicitly pass the include-untracked flag. The reason this is a separate behavior is that Git distinguishes between modifications to existing objects and the creation of entirely new objects. By forcing Git to include untracked files, you are effectively telling the system to take a snapshot of the entire directory state, including new files. This is vital when you are working on a feature that requires adding several new modules, as it ensures your entire workspace is completely cleared when you switch branches, preventing accidental file carry-over into other work areas.
# Stash tracked changes AND any new, untracked files
git stash push -u -m "Stashing everything including new files"
# Verify the working directory is now clean
git statusManaging the Stash Lifecycle
As you continue to stash, your stack will grow, and eventually, you will need to prune it. Managing the stash lifecycle is essential for long-term development hygiene, as keeping outdated changes in your stash can lead to applying the wrong code to the wrong branch later. You can selectively drop individual stashes if you realize that the work contained within them is obsolete. Furthermore, if your stack becomes completely unmanageable or full of dead-end experiments, you can clear the entire stack at once. This is the equivalent of throwing away your physical scratchpad once it is full. By periodically reviewing and purging the stack, you ensure that every time you use a stash, you are dealing with relevant, current code. Understanding that these commands affect hidden references allows you to maintain control over the repository's state without polluting your actual commit history with partial, broken, or unfinished commits that would otherwise appear in the project logs.
# Remove a specific stash entry by index
git stash drop stash@{2}
# Delete all stashes in the stack permanently
git stash clearInspecting Stash Contents
Sometimes, you may have multiple stashes and cannot remember exactly what changes are inside a specific entry. Rather than blindly popping or applying them and hoping for the best, you can inspect the contents using the show command. This command provides a summary of the changes by displaying a diff of the modified files. By passing the patch flag, you can see the exact lines of code changed within each file. This is crucial for verifying that you are restoring the correct piece of work. The reasoning here is similar to reviewing a pull request; you should never merge or apply code without first understanding the delta. This practice prevents you from accidentally overwriting current work with outdated logic from a previous session. It turns the stash from a 'black box' into a transparent, manageable set of temporary storage slots, providing peace of mind as you toggle between different development contexts throughout the day.
# View a summary of what changed in the most recent stash
git stash show stash@{0}
# View the full diff (the actual lines of code) of the stash
git stash show -p stash@{0}Key points
- The git stash command stores uncommitted changes in a hidden stack.
- Stashing is a LIFO stack that allows you to switch tasks without committing unfinished code.
- The pop command applies the changes and removes them from the stack simultaneously.
- You must use the -u flag to ensure untracked files are included in your stash.
- Using stash show allows you to inspect changes before deciding to restore them.
- The stash stack should be periodically cleared to maintain an organized workspace.
- Applying stashes can result in merge conflicts if the underlying file structure has evolved.
- The stash system keeps your actual commit history clean by isolating temporary, incomplete work.
Common mistakes
- Mistake: Expecting git stash to save untracked files by default. Why it's wrong: By design, git stash only tracks modified files that are already staged or tracked. Fix: Use git stash -u or git stash --include-untracked to ensure new files are saved.
- Mistake: Forgetting which stash index belongs to which task. Why it's wrong: Git uses a stack system where the most recent stash is index 0; losing track leads to applying the wrong code. Fix: Always use git stash save "descriptive message" to provide context.
- Mistake: Trying to pop a stash when the working directory has conflicting changes. Why it's wrong: Git refuses to apply a stash if it conflicts with current files, causing a merge error. Fix: Commit your current work or stash it before popping, or resolve conflicts manually.
- Mistake: Confusing git stash pop with git stash apply. Why it's wrong: Pop removes the stash from the stack after applying it, while apply keeps it there. Fix: Use apply if you want to keep a backup or apply the same changes to multiple branches.
- Mistake: Deleting important changes with git stash drop. Why it's wrong: Once dropped, the specific stash entry is gone from the stack forever. Fix: Use git stash clear only if you are certain you want to purge every saved stash.
Interview questions
What is the primary purpose of using 'git stash' in a development workflow?
The primary purpose of 'git stash' is to temporarily shelve or 'stash' changes you have made to your working directory that you are not yet ready to commit. This is incredibly useful when you need to switch branches to fix an urgent bug or perform a pull request review, but your current work is in an incomplete, messy state. By stashing, you restore your working directory to a clean state, matching the HEAD commit, without losing the progress you have made on your feature.
How do you retrieve stashed changes back into your working directory, and what is the difference between 'git stash pop' and 'git stash apply'?
To retrieve changes, you use either 'git stash pop' or 'git stash apply'. The difference is that 'git stash pop' applies the changes and immediately removes the stash entry from the stack, which is ideal if you are finished with that specific set of changes. In contrast, 'git stash apply' keeps the stash entry in your list, allowing you to re-apply the same set of changes to multiple branches or keep them as a backup while you resolve potential merge conflicts.
How can you manage multiple stash entries if you have saved work at different times?
When you stash multiple times, Git creates a stack-like structure. You can view all entries using 'git stash list', which displays them as 'stash@{0}', 'stash@{1}', and so on, with the most recent entry being zero. If you need to target a specific older stash, you can specify it by index, such as 'git stash apply stash@{2}'. This system allows developers to keep multiple contexts alive, moving between different tasks without cluttering their commit history with unfinished work.
Compare the approach of using 'git stash' versus creating a 'temporary commit' to save your work.
While both methods save your work, they serve different purposes. A temporary commit permanently alters your project history, meaning you must later use 'git reset' or an interactive rebase to clean up the branch before merging, which can be risky if not handled carefully. 'Git stash' is superior for ephemeral tasks because it keeps your commit history clean and linear, avoiding the need to fix up the log later, as the stash is never part of the permanent history.
How do you include untracked files in your stash, and why might this be necessary?
By default, 'git stash' only saves tracked files—those that have already been added to the Git index. To include new, untracked files, you must use the '--include-untracked' or '-u' flag, and for ignored files, you can use '-a' or '--all'. This is necessary when you have created new configuration files or assets that are essential for the code to run correctly; otherwise, these files remain in your directory and could cause conflicts when you switch branches.
Explain the process of creating a new branch directly from a stash entry and describe a scenario where this workflow is highly beneficial.
You can create a new branch from a stash using the command 'git stash branch <branch-name> <stash-index>'. This is highly beneficial when you realize your stashed changes have diverged significantly from the main branch or if you encounter merge conflicts while trying to pop the stash. This command checks out a new branch, applies the stash, and automatically drops the stash entry, allowing you to resolve conflicts cleanly without affecting your primary development branch.
Check yourself
1. You have modified a file but have not staged it yet. What happens when you run 'git stash'?
- A.The file is ignored and remains in the working directory.
- B.The file is saved to the stash stack and reverted in the working directory.
- C.The command fails because the file is not staged.
- D.The file is automatically committed to the current branch.
Show answer
B. The file is saved to the stash stack and reverted in the working directory.
Correct: git stash saves all tracked modifications, regardless of staging status. Option 1 is wrong because tracked files are included. Option 3 is wrong because staging is not a requirement. Option 4 is wrong because stashing creates a separate storage entry, not a commit.
2. Which command should you use to see a list of all your saved stashes?
- A.git stash log
- B.git stash view
- C.git stash list
- D.git stash show
Show answer
C. git stash list
Correct: 'git stash list' displays the stack of stashes. 'Log' and 'view' are not valid git stash subcommands. 'Show' is used to see the contents of a specific stash, not the list of all entries.
3. What is the primary difference between 'git stash pop' and 'git stash apply'?
- A.Pop removes the stash after applying; apply keeps it in the stack.
- B.Apply is for staged files; pop is for unstaged files.
- C.Pop is faster than apply.
- D.Apply creates a new commit; pop does not.
Show answer
A. Pop removes the stash after applying; apply keeps it in the stack.
Correct: Pop is a destructive operation that clears the stash entry, whereas apply retains it. The other options describe false functional differences; both work on any modifications and neither creates permanent commits.
4. You have a new, untracked file that you want to include in your stash. What is the correct syntax?
- A.git stash --new
- B.git stash -u
- C.git stash --add-all
- D.git stash --include-staged
Show answer
B. git stash -u
Correct: The -u (or --include-untracked) flag tells Git to stash files not yet tracked. The other options are either invalid commands or incorrect flags for this specific task.
5. If you are working on a feature, stash it, switch to another branch, and realize you need that code back, what is the best workflow?
- A.Use git stash apply on the new branch.
- B.Use git stash checkout to move the stash to the new branch.
- C.Use git stash merge to combine the stash with the current branch.
- D.Use git stash move to transfer the stash.
Show answer
A. Use git stash apply on the new branch.
Correct: Git stashes are global to the repository, so you can apply a stash created on one branch to any other branch. Options 2, 3, and 4 reference commands that do not exist or do not perform that specific action.