Stash is useful when local work should be temporarily set aside without turning it into the next ordinary project commit. Perhaps a fictional revision app has an unfinished layout change, and the student wants to inspect another branch. The work is worth keeping, but it is not ready to present as a completed change. A stash can record it while making selected local state available for another task.

The first question is what must survive the pause. A tracked file edit, a newly created untracked file and an ignored generated file belong to different categories. Saying “my work” is emotionally clear but technically incomplete. The programme needs a more precise description of the files and states to preserve.

The second question is why the work is being paused. A short interruption may suit a stash. Work that needs to be shared, reviewed or continued across several days may be clearer on a branch with a deliberate commit. A separate worktree can also let another checkout coexist without clearing the current one. These are different workflow choices, not competing definitions of the same command.

For a learning session, write a one-sentence goal: “Keep the unfinished tracked edits and the new notes file, then inspect another branch.” That sentence already suggests that the default tracked-only stash may be insufficient. The student has a requirement to compare against the command's actual behaviour.

A parent can ask, “Which files would make you disappointed if they were missing when you returned?” Then let the student use Git's status output to classify them. This connects the human purpose to the technical state, which is the most useful foundation for safe and confident stash use.

Three states are central to a basic Git explanation. HEAD identifies the currently checked-out commit. The index, often called the staging area, records what is prepared for a future commit. The working tree contains the files being edited. A file can have changes staged in the index and additional changes in the working tree at the same time.

For example, a tracked notes file initially says draft. The student changes it to checked and stages that version. Then they change it again to ready without staging the second edit. The index contains checked, while the working file contains ready. The two differences are real and need separate inspection.

git status --short
git diff
git diff --cached

Status provides a summary. The ordinary diff shows unstaged tracked changes relative to the index. The cached diff shows staged changes relative to HEAD. Reading both diffs is more informative than assuming that a filename in status represents only one version of the work.

Stash can record the index and working-tree states associated with the local changes it captures. Restoring the file contents and restoring the original staged arrangement are related but distinct goals. Later, the index option will make that distinction explicit.

Draw three columns for HEAD, index and working tree, and write the relevant version of one line in each. This small state table turns several Git terms into concrete text the student can compare. It also explains why staging does not remove the working file and why a clean status is a statement about relationships between states, rather than proof that nothing valuable exists anywhere in the repository.

A tracked file is known to Git through the index and repository history. An untracked file exists in the working tree but is not currently tracked. An ignored file matches an ignore rule and is normally omitted from ordinary untracked-file reporting. These categories influence what a stash push captures.

By default, a normal stash push records tracked changes, including staged and unstaged work. It does not automatically include every untracked or ignored file in the directory. The include-untracked option adds untracked files; the all option also includes ignored files. Broader capture may be useful, but it should be chosen after inspecting what those extra files contain.

The table describes the basic capture scope for this lesson, without patch selection, path restrictions or other special options. Those later choices can narrow or alter the operation. Avoid combining many options before understanding the simple case.

A new source file is easy to overlook because it sits beside tracked files and feels equally important. Git still treats it differently until it is added. Likewise, an ignored directory may contain generated files, caches or local configuration that you do not want recorded in a stash object. “Capture more” is not automatically a better decision.

Ask the student to identify each category using status and, when necessary, ignored-file reporting. Then predict what remains in the working tree after each capture mode. This prediction is an effective check that they understand the scope rather than treating stash as a universal backup button.

Before creating a stash, inspect the repository, branch and diffs. The purpose is to know exactly what the command is about to capture and what it is about to roll back. A brief inspection is especially valuable when the student has several terminal windows open or has been moving among project directories.

git rev-parse --show-toplevel
git branch --show-current
git status --short
git diff
git diff --cached

The top-level path identifies the repository. The branch name provides context. Status shows the categories of local changes, and the two diffs reveal their content. These checks answer different questions; one does not substitute for all the others.

For a learning project, look at the changed text rather than relying only on a summary count. A diff showing one altered file may contain an unfinished paragraph, an accidental deletion or a local setting that should not be captured. The stash command will not decide which of those meanings matters to the project.

If there are unmerged paths from an existing conflict, stop treating the repository as an ordinary clean-base stash exercise. Resolve the current situation through its appropriate workflow before adding another operation. A beginner should first practise stash from a known state, not use it as an unexplained rescue command during several overlapping Git operations.

Write a short note beside the intended command: which branch, which files and whether staging should be restored later. That note can also become a useful stash message. The aim is not a long checklist for every tiny edit; it is a clear enough understanding that the student can compare the state after the command with the state they intended to preserve.

A message makes a stash easier to recognise later. The command below records ordinary tracked local changes with a description of their purpose. In a real project, use a message that identifies the unfinished task rather than copying this example literally.

git stash push -m "Pause task-card wording before branch review"
git stash list
git status --short

The stash list should show the new entry, usually at the newest position. For an ordinary tracked-only case without special options, the captured tracked changes are rolled back in the working tree and index to the relevant HEAD state. Untracked files excluded from capture can remain, so status may still show them.

The command may report that there are no local changes to save. Do not assume that a new stash exists merely because a command was typed. Read the result and inspect the list. A new ignored file alone, for example, does not create the tracked-change snapshot expected from an ordinary push.

A stash message is a label, not a proof of completeness. A message saying “all work” does not alter the capture options. The saved contents determine what is present. This is why the next step is inspection, particularly when the operation was intended to include new files.

Students sometimes feel worried when their edits disappear from the visible files. Explain that rolling back the selected local state is part of the pause operation. The evidence that the work was retained is the recorded entry and its inspected contents, not the fact that the working file still contains the unfinished text. In a disposable lab, compare the file before and after push so the state transition becomes familiar and predictable.

Stash list gives descriptions and selectors. Stash show provides a summary or a patch of the saved changes. For a stash that captured untracked files, include those files in the inspection explicitly so the review matches the intended capture scope.

git stash list
git stash show --stat 'stash@{0}'
git stash show -p --include-untracked 'stash@{0}'

The quotes protect the selector from shell interpretation in environments where special characters matter. The explicit selector also makes the intended entry visible in the command. Omitting a selector generally means the latest entry, which can be convenient but is less clear when several stashes exist.

The patch should contain the edits the student intended to preserve. If a new notes file was supposed to be included but is absent, inspect the push options and the file's category. Do not immediately drop the stash or overwrite the notes while investigating. The working tree and stash may contain different parts of the intended work.

Read the patch as a comparison against the base commit recorded with the stash. It describes saved changes, not a prediction that those changes will apply without conflict to every other branch. Restoration still depends on the current destination state.

A useful exercise is to hide the stash message and ask the student to identify the task from the patch. If the changes tell a clear story, the message can summarise that story. If the patch contains several unrelated tasks, consider whether future work should be organised more deliberately. Stash can store mixed changes, but a named entry with a coherent purpose is easier to inspect, restore and eventually remove with confidence.

A stash is stored in the local repository. An ordinary push of branch commits to a remote does not automatically transfer the stash list as shared project work. If the student needs the unfinished work on another machine or another collaborator needs to review it, use an appropriate sharing workflow, such as a branch with a deliberate commit.

This distinction explains why stash should not be treated as the only backup for important work. Its local storage may protect against a short branch-switch interruption, but it does not by itself address loss of the machine or repository directory. The right preservation method depends on the consequence of losing the work and the period over which it must remain accessible.

There is no need to frighten a beginner with elaborate recovery scenarios. Simply state the boundary: a stash is a local pause mechanism, and sharing or durable preservation needs an explicit plan. A small work-in-progress commit on an appropriate branch may be easier to understand for a project that will continue over several sessions.

The stash entry also records a base relationship in repository history. That helps Git attempt to reapply the changes later, but it does not mean the entry is permanently attached to the original branch as a rule preventing use elsewhere. The branch name displayed in the message provides context; the current target branch still matters when applying.

Ask the student where the stash would be found after opening a fresh clone elsewhere. The ordinary clone will not contain that local stash list. Then ask what they would do if the work needed to be shared with a project partner. A strong answer chooses a deliberate branch-and-commit workflow rather than assuming that the word save implies remote storage.

Apply attempts to restore a selected stash on top of the current state and keeps the stash entry in the list. This is a useful first restoration choice in a learning lab because the saved entry remains available while the student inspects the restored result.

git status --short
git stash apply 'stash@{0}'
git status --short
git diff
git diff --cached
git stash list

Begin from a known destination state. Applying on top of unrelated local edits can make the result harder to explain or cause Git to refuse the operation to avoid overwriting work. A clean, disposable lab isolates the behaviour being studied.

After apply, check the intended files and staging separately. An ordinary apply does not promise to reinstate the original staged arrangement. The saved content can be restored while appearing differently in the index. If staging matters, the index option deserves its own deliberate test.

Keeping the entry is helpful, but it does not make repeated apply calls harmless. Once the changes are present, applying the same stash again can fail or interact with later edits. The saved entry remains a source to inspect, not an instruction to reapply repeatedly until the programme looks right.

For practice, create one tracked text edit, stash it and apply it once. Compare the file and the list after restoration. The text should be back, and the stash should still exist. Ask the student to explain those two observations separately. That explanation establishes the difference between restoring content and removing its temporary saved reference, which is essential for understanding pop.

Pop attempts to apply a selected stash and remove that entry after a successful application. This combines two jobs that apply keeps separate. It is convenient when the entry is no longer needed, but the student should understand both consequences before using it.

git stash pop 'stash@{0}'
git status --short
git stash list

On success, the restored work should be inspected and the entry should no longer appear in the stash list. When application fails with conflicts, Git retains the stash entry so that the recorded work is not simply discarded by the failed pop. Read the command's result and inspect both status and the list instead of assuming that every pop removed the entry.

This conflict behaviour is a common source of confusion. A student may resolve the files and later discover that the old stash is still listed. That does not necessarily mean the restored changes vanished or that the resolution failed. The entry survived the conflicted application and needs a later deliberate cleanup decision after verification.

Apply is often easier for a first lesson because restoration and removal can be checked independently. Pop is not inherently wrong; it is just a combined operation whose outcome must be understood. A learner should be able to choose between them based on whether they want to retain the recorded source while reviewing the result.

Ask the student to complete two sentences: “Apply keeps the entry after…” and “Pop removes the entry after…”. They should include successful application in the second sentence and recognise the conflict exception. This little retrieval check prevents the inaccurate shortcut that pop always deletes first or that it always removes the entry regardless of the restoration outcome.

A stash can preserve information about staged and unstaged changes. When that original staging arrangement matters, apply or pop can be given the index option to attempt to restore it as well as the working-tree changes. This is a separate goal from merely getting the latest file content back.

git stash apply --index 'stash@{0}'
git diff --cached
git diff

For a clear experiment, start with one tracked file. Stage one change, then make an additional unstaged change in the same file. Save the stash. On a clean compatible base, apply with the index option and inspect both diffs. The staged diff should represent the staged part, while the ordinary diff should represent the remaining working-tree change.

The word attempt matters. Conflicts can prevent the original index state from being reinstated. The current branch and working state may also be incompatible. Do not promise that one option guarantees an exact staging restoration under every condition.

Why might this matter? A student may have intentionally prepared one small change for a commit while leaving another experiment unstaged. Restoring only the final file content loses that prepared boundary unless the student stages the intended part again. Restoring the index can preserve the earlier work organisation when the destination allows it.

Ask the learner to explain the difference between “the file contains all my text” and “the staging area contains the part I intended to commit”. Both can be true, or only the first may be true. A reliable Git explanation treats them as separate observations. This distinction is valuable well beyond stash because many commit mistakes begin with an assumption that the visible working file and the staged version are identical.

The include-untracked option is appropriate when the unfinished task contains new files that have not been added to the index. Inspect those files first, then use the option and verify that they are represented in the saved entry.

git stash push -u -m "Pause tracked edits and new exercise notes"
git stash show -p --include-untracked 'stash@{0}'
git status --short

After a successful capture, the included untracked files are removed from the working tree as part of setting aside that state. This can be alarming if the student expected them to remain visible. The correct evidence is the inspected saved entry and, later, the verified restoration.

An untracked file is not automatically harmless. It may contain local information or a large generated output that does not belong in the intended task snapshot. The student's purpose should determine whether to add it, stash it or leave it separate. The broad category tells Git how to treat the file; the content tells the person whether that treatment is appropriate.

Restoring a saved untracked file can fail if a file already exists at the same path in the destination. Do not assume that every successful restoration of tracked changes guarantees that every untracked file was restored too. Read the command output and inspect the paths that mattered to the original goal.

For a small exercise, create one tracked edit and one new notes file, then compare ordinary push with push using include-untracked in separate fresh labs. The first leaves the new notes file outside the stash. The second captures it. The comparison teaches a precise scope rule and avoids the misleading statement that stash either always saves everything or never saves new files.

Ignored files are often generated outputs or local configuration. The all option can include them in a stash along with untracked and tracked changes. That broader capture is sometimes useful, but it should follow an inspection of the ignored paths rather than a habit of always using the broadest option.

git status --short --ignored
git stash push -a -m "Pause a reviewed local lab state"
git stash show -p --include-untracked 'stash@{0}'

The example belongs in a disposable lab whose files are known. In an important project, ignored directories may be large or may contain information that the author deliberately excluded from ordinary history. Stashing records objects in the repository even though the entries are local, so the content still deserves a conscious decision.

An ignore rule does not mean that a file is automatically a backup or that Git has preserved its current contents elsewhere. It means the path is normally excluded from ordinary untracked reporting and addition behaviour. A student who deletes an ignored output on the assumption that Git must have saved it is relying on the wrong interpretation.

The lesson is to keep three ideas separate: a file's category, the capture option and the preservation requirement. An ignored cache may not need preservation. A local configuration may need a different controlled handling method. A tiny ignored lab file may be appropriate for demonstrating all-mode behaviour.

Ask the learner to describe why a particular ignored file exists and whether it can be reproduced. That practical question is more useful than treating ignored as a universal synonym for disposable. Then choose the workflow. The command should implement the decision, not make it invisibly on the person's behalf.

The keep-index option lets already-staged changes remain in the index and working tree while other changes are set aside. One use is testing a prepared staged change without the additional unfinished edits affecting the test. This requires a clear understanding of which changes were staged beforehand.

The stash entry can still record the staged state, so keep-index does not mean that staged changes never appear in the saved entry. Its immediate working-state purpose is to leave the index's changes intact. That distinction prevents an oversimplified explanation of what the option excludes.

git diff --cached
git stash push --keep-index -m "Set aside extra edits while checking staged work"
git status --short
git diff --cached

Inspect before and after. The staged work should remain available for the intended test in a compatible ordinary case. The unstaged work that was selected for the stash is set aside. If the student cannot explain the two states in one file, return to the earlier three-column model before using this option.

Another option, staged, selects staged changes for stashing, and it has its own constraints and interactions. Do not treat it as a different spelling of keep-index. One workflow preserves staged work in place while pausing other work; the other aims to stash the staged selection. Consult the installed version's help when using a less familiar option.

For a first course of practice, ordinary push, include-untracked, apply and index restoration are enough. Keep-index is a useful extension once the learner has a genuine staged-versus-unstaged requirement. Adding every option in one session can obscure the simple state relationships that make those options understandable.

Stash push can be restricted to selected paths, and patch mode can interactively select hunks of tracked changes. These features help when a working tree contains unrelated tasks. Their value comes from a deliberate selection, not merely from the command becoming more sophisticated.

git stash push -m "Pause only task-card edits" -- task-card.txt
git stash show -p 'stash@{0}'
git status --short

The double hyphen separates options from the path specification. The example restricts the operation to the named tracked path in the ordinary lab. Other local changes can remain, so the repository may still be unsuitable for the branch switch the student intended. Inspect the result rather than assuming that any stash command produces a completely clean working tree.

Patch mode asks the user to choose parts of a diff. It can be useful, but the selected hunks need to form a meaningful change. Pausing half of a tightly coupled edit may leave both the visible working state and the stored state difficult to test. The code's dependency structure matters alongside the textual selection.

Patch mode also has option interactions, including keep-index behaviour described by Git's manual. Use a small lab and the current help before relying on a combination. A beginner does not need to memorise every interaction; they need to know that capture scope and retained working state are separate questions.

After a selective operation, write down which files or hunks remain and why. This makes the next action reviewable. The student should be able to say, “I paused the layout wording, while the unrelated calculation edit is still here.” That explanation is much more useful than a vague claim that they “cleaned up Git”.

A stash can be applied on another branch. The branch named in its description records where it was created; it does not force every restoration to happen there. Before applying, identify the current branch and consider whether the saved changes make sense against that branch's files and history.

Suppose a fictional task-card edit was made on a design branch, while the student now checks out a simpler maintenance branch. The same file may exist but contain different surrounding text. Git may apply the patch cleanly, produce conflicts, or refuse a problematic operation. Even a clean textual application does not prove that the change belongs in the destination's behaviour.

This is the same distinction students meet in other programming tasks: syntactic success is not semantic correctness. Restoring a button label into a branch that lacks the corresponding feature can produce a misleading interface even when the patch applies without complaint. The author must review the result in context.

Use a clean destination in the first lab to make the comparison simple. Inspect the branch, status and relevant base content. Then apply, inspect the diff and run the relevant small check. The question is not merely “did Git return success?” but “did the intended work arrive in the intended place with a sensible result?”

If the goal is to move an already committed change rather than pause uncommitted local work, the existing Git cherry-pick lesson addresses that separate reader job. Stash and cherry-pick both relate to changes, but their source states and workflow purposes differ. Choosing between them starts with identifying what has already been committed.

A conflict during stash application means Git could not automatically reconcile parts of the saved changes with the current destination. It does not prove that the stash is corrupted or that all the student's work is gone. The useful response is to inspect the affected files and understand the competing versions.

Status identifies unmerged paths. A conflicted text file may contain marker lines separating alternatives. Read the surrounding text and the intended requirement. The correct result may use one side, combine both sides or be a new formulation that satisfies the destination's design. Choosing a side mechanically can discard useful information.

Stash conflict labels may refer to updated upstream and stashed changes. Do not blindly map every label to branch ownership or assume that ours always means the student's preferred version. The operation context determines what the alternatives represent. The learner should identify the actual text and its purpose.

After editing a resolution, remove all conflict markers and check that the file is valid for its type. Stage the resolved path when appropriate to mark the conflict resolved. Then inspect status and diffs and run the relevant project check. Staging a resolution confirms Git's bookkeeping state; it does not by itself prove that the resulting programme works.

A conflicted pop retains the stash entry. Keep it while reviewing the resolution, then make a separate cleanup decision when the restored work is demonstrably present. A conflict exercise is best done in a disposable repository with two simple competing lines. That small example lets the student reason about the comparison rather than panic about a large project full of unfamiliar changes.

Stash application does not use the same sequencer workflow as operations such as a multi-commit cherry-pick. There is no ordinary stash continue command to finish a conflict resolution, and no general stash abort command that automatically rewinds every aspect of an application. This is important because students often transfer commands from another Git operation without checking the context.

In a simple conflict resolution, edit the file, stage the resolved path if needed, inspect the result and decide how to preserve the restored work. If the work should become a commit, create that commit through the ordinary commit workflow after appropriate checks. If it should remain uncommitted, understand the current staged and unstaged states rather than searching for a nonexistent continuation step.

Abandoning a failed application requires a deliberate plan based on the state that existed before it. A broad reset or cleanup can erase unrelated work if the destination was not clean. This is why the lab starts from a known clean base and why important work should be inspected before restoration. Do not copy a destructive cleanup command into an unknown repository just because an internet example used it in a disposable exercise.

For the learning lab, retaining the stash with apply allows another fresh disposable checkout or branch-based recovery experiment if needed. The student can compare the recorded source with the current result. The preserved entry is helpful evidence, but it does not remove the need to reason about files already changed by the application.

Ask the learner to explain how this differs from cherry-pick continue. They should identify the operation first, then choose its relevant resolution workflow. That habit prevents Git from becoming a list of remembered rescue commands used without regard to what is currently happening.

Git stash branch creates a new branch from the commit at which the stash was originally created and attempts to apply the recorded state there. This can help when the current branch has changed enough that applying the stash on top of it is awkward or conflicted.

git status --short
git stash branch resume-task-card 'stash@{0}'
git status --short
git stash list

Choose an unused branch name and begin from an appropriate working state. The new branch provides a context close to the saved work's original base. It is not a promise that the unfinished project is correct or that no later integration work will be needed. The purpose is to recover and continue the paused state in a suitable context.

When the specified stash is an entry from the stash list and application succeeds, the command drops that entry. That combined behaviour deserves attention, much like pop. Inspect the result and preserve the continued work through an appropriate commit before treating the temporary saved entry as unnecessary.

This workflow separates recovery from integration. First, make the paused work understandable and complete on its own branch. Later, decide how to integrate it with the current project. Trying to solve both at once can make a beginner's conflict much harder to interpret.

For practice, create a stash on a base with a simple line, then change that line on the current branch. Rather than repeatedly attempting a conflicted application, try stash branch in a fresh lab. Explain why using the original base changes the comparison problem. The student should see a specific reason for the command, not treat it as a magic alternative whenever another command returns an error.

The following commands create a new local repository for practice. Run them only in a fresh exercise directory. The local user settings apply to this lab repository rather than changing global Git configuration. There is no remote and no publishing step.

mkdir stash-learning-lab
cd stash-learning-lab
git init -b main
git config user.name "Learning Lab"
git config user.email "lab@example.invalid"
printf 'status: draft\n' > plan.txt
printf '*.tmp\n' > .gitignore
git add plan.txt .gitignore
git commit -m "Create lab baseline"
printf 'status: checked\n' > plan.txt
git add plan.txt
printf 'status: ready\n' > plan.txt
printf 'Remember the diagram\n' > notes.txt
printf 'Generated lab output\n' > preview.tmp
git status --short --ignored
git diff --cached
git diff

The tracked plan file now has a staged change from draft to checked and an unstaged change from checked to ready. Notes is untracked. Preview matches the ignore rule. These four states provide a compact demonstration of the capture policies discussed earlier.

Before stashing, write the expected state of each file after an ordinary push and after a push with include-untracked. The ignored preview should remain under include-untracked; the notes file should be captured and removed from the working tree. The tracked plan should return to the baseline in the ordinary capture case.

Do not rush to the next command until the two diffs make sense. The same filename appears in both because two different comparisons are being shown. The file's current visible text is ready, but the prepared staged version is checked. This one-line lab is a particularly effective way to make that distinction concrete.

Continue the lab by capturing the tracked changes and the untracked notes. The ignored preview remains outside this stash. Inspect the saved entry before restoring it with the index option.

git stash push -u -m "Lab: staged and unstaged plan plus notes"
git status --short --ignored
git stash show -p --include-untracked 'stash@{0}'
git stash apply --index 'stash@{0}'
git status --short --ignored
git diff --cached
git diff
git show :plan.txt
cat plan.txt
cat notes.txt
git stash list

After push, plan should be back at draft. Notes should be absent from the working tree but represented in the saved entry. Preview should remain as an ignored file. After the compatible apply with index restoration, the staged plan version should be checked, while the working file should be ready. Notes should return with its original text. Apply keeps the stash listed.

These are separate expectations, so verify each one. A single status screenshot does not show the actual contents of every relevant state. The show command with a leading colon reads the index version of the tracked path. Cat reads the working-tree file. Comparing those two outputs makes staging restoration observable.

If an expectation fails, stop and record the actual result before modifying more state. Check whether the command ran in the correct directory, whether the base was clean and whether the local Git version supports the options used. A small lab should remain a controlled experiment.

Finally, explain the result without looking at the commands. The learner should name what was captured, what remained outside, how the two plan versions were restored and why the stash still exists. That explanation demonstrates a more durable understanding than merely completing a terminal transcript successfully.

Stash selectors such as stash at zero and stash at one refer to positions in the current stash list. Adding or removing entries can change those positions. A command written yesterday with the selector for the second entry may point to different work after the list changes.

Before applying or dropping an entry, inspect the current list and the selected patch. The message, base context and contents together identify the intended work. Do not rely on a remembered position alone. This is a small but important habit when several paused tasks accumulate.

Git can resolve a stash selector to an object identifier. Recording that identifier can help keep a particular snapshot unambiguous for inspection and application, while dropping an entry remains a deliberate list-reference operation. The important beginner lesson is simpler: positional selectors are not permanent task names.

A messy stash list can also signal a workflow issue. If many entries remain for weeks with vague labels, consider recovering them onto named branches, completing the useful work and removing verified obsolete entries individually. Do not clear the entire list merely to make the display look tidy.

For practice, create two small entries with distinct messages in a fresh lab. Inspect the newest and older patches, then add a third entry and observe the selectors change. Ask the student which facts still identify the original task. The patch contents and context remain meaningful; the list position has moved. This exercise connects a familiar data principle to Git: a display position is different from a stable identity, and commands should be grounded in the current state.

Drop removes a selected stash entry from the list. Clear removes the stash list as a whole. These cleanup operations deserve a deliberate decision because the stored work may no longer be conveniently recoverable afterwards. For a beginner, individual cleanup after verification is easier to reason about than broad clearing.

git stash list
git stash show -p --include-untracked 'stash@{0}'
git status --short

Use these inspections to identify the selected entry and confirm where its useful work now lives. Has it been restored and reviewed? Has it been committed on an appropriate branch? Were the new files included in that preserved result? A successful apply followed by an unchecked deletion is weaker evidence than a verified file comparison and an intentional commit.

Only after that decision should the student use drop with the current selector for the intended entry. The cleanup command is omitted from the inspection block so the reader makes the decision consciously rather than executing it as part of an unquestioned transcript. In the disposable lab, it is reasonable to drop the test entry once every expected state has been checked.

Recovery of dropped stash objects can sometimes be possible while underlying objects remain, but it is not a dependable substitute for deliberate preservation. Do not teach that dropping is harmless because a complicated recovery command might work later. The practical rule is to verify the replacement before removing the temporary reference.

Ask the learner to state the evidence for cleanup in one sentence: “The restored notes and both plan changes have been checked and preserved on this branch.” That is a stronger reason than “the stash is old”. Age alone does not establish that the work is obsolete or safely stored elsewhere.

Close the command examples and answer four questions. Does ordinary stash push include a new untracked notes file? No. Does include-untracked also capture an ignored preview file? No. Does ordinary apply remove the stash entry? No. Does a conflicted pop automatically remove its entry? No; the entry is retained when the application conflicts. Explain the relevant scope or outcome condition for each answer.

Next, describe a tracked file with one staged edit and one additional unstaged edit. Which checks reveal both differences? Cached diff shows the index against HEAD, while ordinary diff shows the working tree against the index. Which restoration option attempts to reinstate the saved staging arrangement? The index option on apply or pop.

For a transfer question, a student needs unfinished work on another computer. Should they assume an ordinary remote push transfers the local stash list? No. They need a deliberate sharing workflow, often a branch with a commit. This question checks the boundary of the tool rather than another spelling detail.

In a Punggol family session, a parent can ask the learner to explain what changed before and after one command. Keep the discussion to the disposable lab. The parent does not need to adjudicate an important repository's conflict or memorise every option. Useful support means asking for the intended state, actual evidence and next small step.

If a tutor's help is needed, bring status, both diffs, the stash inspection and the exact command result. Describe whether the problem concerns capture scope, staging restoration, target branch or conflict resolution. These details make the issue specific and teachable. Use How Studying Works to connect explanation, independent practice and correction rather than repeating commands without understanding their state changes.

The official git-stash manual describes push, list, show, apply, pop, branch and their options. The git-status manual explains state reporting, while the git-diff manual explains the comparisons used throughout the lab. Check the help for the installed Git version when using a less familiar option or combination.

For alternatives, the git-worktree manual describes working with additional checkouts. A separate worktree can be useful when another task should be inspected without clearing the current working tree. A branch with a deliberate commit is often clearer when work needs to be shared or retained across a longer period. Choose the workflow that matches the real task.

A learner is ready to use stash more independently when they can identify file categories, inspect the two tracked-change comparisons, choose capture scope and predict what remains after push. They should also explain apply versus pop, the purpose of index restoration and the need to inspect the destination before applying.

The final check is recovery reasoning. If a conflict occurs, can the student identify the affected text, preserve the saved source while reviewing a resolution, and avoid borrowing an unrelated continue or abort command? If not, practise one small conflicting line in a disposable repository before using stash around important work.

Git stash becomes dependable when it is treated as a specific state operation. Identify what should be paused, inspect what was recorded, restore into a suitable context, verify the result and remove the temporary entry deliberately. Those habits let a student switch attention with a clear account of where the unfinished work lives and how to continue it.