Two small tools keep a working tree under control. git stash gives you a drawer for work that isn’t ready to commit. .gitignore tells Git which files it should never track at all. Both prevent the same kind of accident: the wrong thing ending up in a commit.
You’re halfway through the portfolio’s contact form on the contact-form branch when someone points out a typo on the live home page. You need main, now. But git switch main refuses, because your edits to index.html would be overwritten, and you don’t want to commit a half-built form.
Stash it:
\ngit stash push -m \"contact form: fields done, validation next\"\ngit status # nothing to commit, working tree cleanYour changes, staged and unstaged, are saved in a stash entry and removed from the working tree. Now fix the typo:
\ngit switch main\n# fix, commit, push\ngit switch contact-form\ngit stash poppop reapplies the most recent stash and deletes it. You’re back exactly where you were.
The other stash commands you’ll use:
\ngit stash list # stash@{0}: On contact-form: contact form: fields done…\ngit stash show -p stash@{0} # the diff inside a stash\ngit stash apply stash@{1} # reapply but keep the stash\ngit stash drop stash@{1} # delete one stash\ngit stash push -u -m \"…\" # include untracked (new) files tooThat last flag matters. By default stash only saves changes to tracked files. A brand-new contact.js stays in your folder, untouched, which surprises people when they pop and it isn’t “restored”. Use -u whenever you’ve created files.
Stashes aren’t tied to a branch: you can pop one onto any branch, which is occasionally handy and occasionally a surprise. If you realise the stashed work deserves its own branch after all, git stash branch contact-validation creates a branch at the commit where you stashed, applies the stash there and drops it, which sidesteps conflicts with anything that has changed since.
If pop hits a conflict, Git applies what it can, marks the conflict as usual, and keeps the stash instead of dropping it. Resolve, git add, and run git stash drop once you’re sure.
Some files belong in your project folder but never in history:
\nnode_modules/;dist/;.env;.DS_Store on macOS.List them in a file called .gitignore at the repository root and commit it, so everyone on the project shares the rules:
# Dependencies\nnode_modules/\n\n# Build output\n/dist/\n\n# Local environment and secrets\n.env\n.env.*\n!.env.example\n\n# OS and editor files\n.DS_Store\n*.logIgnored files disappear from git status and git add . skips them.
Each line is a pattern, matched against paths relative to the .gitignore file’s folder:
# starts a comment, but only at the beginning of a line. Blank lines are ignored.*.log matches any file ending in .log, in any folder./ matches directories only: node_modules/./ anchors the pattern to this folder: /dist/ ignores the root dist but not src/dist.**/ matches any depth: **/fixtures/*.json.! re-includes something an earlier line excluded: !.env.example keeps the template for other developers. It can’t re-include a file whose parent folder is excluded, because Git never looks inside an ignored folder.When a file is ignored and you don’t know why, ask Git:
\ngit check-ignore -v dist/app.js.gitignore:5:/dist/\tdist/app.jsIt prints the file, line number and pattern responsible.
\nFor clutter that only your machine creates, don’t burden every project’s .gitignore. Git also reads a global ignore file, ~/.config/git/ignore, which is a good home for .DS_Store and editor folders. GitHub keeps a collection of starter .gitignore templates for most languages, and offers one when you create a repository.
.gitignore only affects untracked files. If .env was committed before you ignored it, Git keeps tracking it. Remove it from the index and commit, which keeps your local file:
git rm --cached .env\ngit commit -m \"Stop tracking .env\"Your working tree is now clean and your repository holds only what it should. Next you’ll make what it holds readable: commit messages, tags and releases.
\n","toc":[{"id":"sec-1","text":"Stash: a drawer for unfinished work","level":2},{"id":"sec-2","text":".gitignore: files Git should never track","level":2},{"id":"sec-3","text":"How patterns work","level":2},{"id":"sec-4","text":"Ignoring doesn’t untrack","level":2}],"takeaways":["git stash push -m "…" saves your uncommitted changes and cleans the working tree; git stash pop brings them back and removes the stash.","git stash skips untracked files unless you add -u (--include-untracked).",".gitignore only affects untracked files; to stop tracking a committed file, run git rm --cached and commit.","In .gitignore, a trailing / matches directories only, a leading / anchors to that folder, and ! re-includes a file.","A secret that was ever committed and pushed must be revoked and replaced, because history still contains it."],"further":[{"title":"git stash reference","url":"https://git-scm.com/docs/git-stash"},{"title":"gitignore pattern format","url":"https://git-scm.com/docs/gitignore"},{"title":"Ignoring files (GitHub Docs)","url":"https://docs.github.com/en/get-started/git-basics/ignoring-files"}],"quiz":[{"q":"You’re halfway through the contact form when an urgent typo fix is needed on main. git switch main refuses because it would overwrite your changes. What’s the quickest clean route?
git restore ., fix the typo, and redo the form later.","why":"That throws away real work to save a few seconds. Stash keeps it safely."},{"text":"git stash push -m "contact form wip", switch to main, fix and commit, switch back, git stash pop.","why":"Correct. The stash holds your half-done work while the working tree is clean, and pop brings it back where you left off."},{"text":"Force the switch with git switch -f main.","why":"-f throws away your local changes to make the switch, exactly what you wanted to avoid."},{"text":"Commit the half-finished form to main with the message “WIP”.","why":"You’d be putting broken work on main. If you want a WIP commit, make it on your feature branch."}],"answer":1},{"q":"You stashed, switched branches, and came back. git stash pop restored your edits to contact.html but your new file contact.js is missing. Why?
git stash pop restores files in the order they were edited and stopped early.","why":"Pop restores everything in the stash at once. The file was never in the stash."},{"text":"The file was deleted by switching branches.","why":"Switching leaves untracked files alone. It was the stash that skipped it, which is why it may still be in your folder."},{"text":"Stashes expire after one branch switch.","why":"Stashes stay until you drop or pop them. git stash list shows them."},{"text":"git stash doesn’t include untracked files unless you pass -u, so contact.js was left behind in the working tree.","why":"Correct. Untracked files aren’t stashed by default. Check the working tree, it’s probably there, and use git stash -u next time."}],"answer":3},{"q":"You committed .env last week. Today you add .env to .gitignore, but git status still shows .env as modified. Why?
.gitignore only applies to untracked files, and .env is already tracked; run git rm --cached .env and commit.","why":"Correct. --cached removes it from the index (so future commits don’t include it) while leaving the file on disk."},{"text":"The pattern needs to be /.env/ to work.","why":"A trailing slash makes a pattern match only directories, so /.env/ wouldn’t match the file at all."},{"text":".gitignore changes take effect only after a push.","why":"Ignore rules apply immediately, locally. The problem is that tracked files are never ignored."}],"answer":0},{"q":"Which .gitignore line ignores the dist folder at the project root but not a src/dist/ folder?
dist","why":"Without a slash at the start or middle, the pattern matches dist at any depth, including src/dist."},{"text":"**/dist/","why":"**/ means at any depth, so this also matches src/dist/."},{"text":"/dist/","why":"Correct. The leading slash anchors the pattern to the folder containing the .gitignore, and the trailing slash limits it to directories."},{"text":"!dist","why":"! re-includes a previously ignored path; on its own it ignores nothing."}],"answer":2}],"exercise":{"kind":"spot-bug","language":"text","code":"# Dependencies\nnode_modules/\n\n# Build output from the Sass experiment\n*.css\n\n# Local environment (never commit secrets)\n.env\nsecrets.json # API keys\n!.env.example\n\n# OS and editor files\n/.DS_Store\n.vscode/\n*.log","bugLines":[5,9,13],"title":"Fix the portfolio's .gitignore","prompt":"This .gitignore sits at the root of the portfolio repository, which contains index.html, styles.css, projects.html, a .env with an API key, secrets.json, and macOS .DS_Store files in several folders. Three lines don’t do what their author intended. Select them.
.gitignore only work in one position on a line.",".DS_Store files appear in every folder macOS has opened, not only the root."],"explanation":"Line 5, *.css, ignores every CSS file, including your hand-written styles.css; ignore only the real build output folder instead (for example /dist/). Line 9 has a trailing comment, but # starts a comment only at the beginning of a line, so the pattern is the literal text secrets.json # API keys and secrets.json is not ignored; move the comment to its own line. Line 13, /.DS_Store, is anchored to the root, so .DS_Store files in subfolders still show up; drop the leading slash (.DS_Store), or better, put it in your global ignore file. The !.env.example line is fine: it keeps the template file other developers need.