Stashing and .gitignore

INPUT · Slides

Stashing and ignoring changes (stash / .gitignore)

01 / 10

Unfinished work and files that should not be committed

Previously, your choices were binary: commit changes or discard them. However, real-world development frequently involves cases in between:

Unfinished code in progress … not ready to commit, but you cannot afford to discard it
Files that must never be committed … passwords, API keys, build logs, dependency folders

In this chapter, you learn how to handle both cases using git stash (temporary shelving) and .gitignore (exclusion rules).

02 / 10

Branch switching rejected when uncommitted changes exist

Suppose you are partway through implementing a feature when an urgent production bug needs immediate fixing.

However, your working tree contains incomplete edits. If you try to run git switch with dirty uncommitted changes, Git refuses the branch switch to prevent overwriting your edits.

Yet you do not want to commit broken, untested code to your branch either. This is precisely when git stash is used.

$ git switch fixerror: Your local changes would be overwritten by switch.

03 / 10

git stash — Temporarily shelving changes

Running git stash takes all uncommitted modifications from both your working tree and staging area and saves them to a temporary stash storage.

Your working tree is cleanly reset to match the latest commit, enabling you to safely switch branches and work on urgent tasks.

Your edits are not deleted; they are preserved safely within Git's internal stash list.

$ git stashSaved working directory and index state WIP on main: 9f2a1c4 made the base$ git statusOn branch mainnothing to commit, working tree clean

04 / 10

git stash pop and git stash list — Inspecting and restoring

When your urgent task is complete and you switch back to your feature branch, run git stash pop to re-apply your stashed changes to your working tree.

Running pop restores the changes and deletes the entry from the stash list.

You can inspect currently saved stashes using git stash list. stash@{0} represents the most recently stashed state.

$ git stash liststash@{0}: WIP on main: 9f2a1c4 made the base$ git stash pop$ git statusChanges not staged for commit:	modified:   app.js

05 / 10

Files that must be kept out of version control

Now let us cover .gitignore.

Running applications produces generated files: runtime logs, temporary caches, compiler artifacts, and files containing credentials (passwords or private keys).

Leaving these files untracked in git status causes two significant risks:

1. Important code diffs get obscured by file clutter
2. Running git add . risks accidentally committing sensitive credentials

Accidentally pushing passwords or API keys to a remote repository is a critical security vulnerability; deleting them in a later commit leaves them exposed in Git history.

06 / 10

.gitignore — Specifying exclusion patterns

Create a plain text file named .gitignore in the repository root and list the files or glob patterns you want Git to ignore, one per line:

*.logtmp/secret.txt

*.log … ignores any file ending with the .log extension
tmp/ … ignores the entire tmp directory and all its contents
secret.txt … ignores the exact matching file

Ignored files will no longer appear in git status and will be excluded from git add ..

07 / 10

The .gitignore file itself is committed

A common question from beginners is whether .gitignore should be committed.

The .gitignore file itself must be committed to the repository.

Project ignore rules are shared team conventions. Every developer and CI pipeline needs the exact same ignore rules applied consistently.

Always git add .gitignore and commit it along with other project configuration files.

08 / 10

Warning: tracked files are not ignored by .gitignore

This is the single most common pitfall with .gitignore.

Files that were already committed to the repository will not be ignored, even if you add them to .gitignore later.

.gitignore only prevents untracked files from being added to the index. It does not untrack files that are already tracked.

To ignore an already tracked file, you must first remove it from Git's index.

$ git rm --cached secret.txtrm 'secret.txt'$ git commit -m "stopped tracking the secret file"

09 / 10

git rm --cached — Untracking while keeping local files

Running git rm with the --cached option removes the file from Git's tracking index while preserving the actual file on your local disk.

Omitting --cached deletes the file from disk as well, so always specify --cached when you only want to stop tracking.

Once untracked and committed, the file becomes untracked, allowing the rule in .gitignore to take effect.

Note: past commits still retain the file. If credentials were committed, immediately revoke and rotate the keys.

10 / 10

How to approach the exercises

When creating .gitignore, ensure the leading period . is included in the filename.

Files successfully ignored will display a muted gray badge and disappear from the untracked file list in git status.

Stashed changes can be viewed in the stash panel at the bottom of the interface.