5 exercises on the everyday Git loop in English: staging and unstaging changes, writing and amending commit messages, stashing, and discarding work.
Key patterns
stage / unstage changes via the staging area (index)
write a commit message; amend a commit
stash changes, then pop / apply the stash
discard changes → restore the committed version
clean vs dirty working tree
0 / 5 completed
1 / 5
Before committing, you select exactly which modified files go into the next commit using git add. The verb for moving changes into that holding area is to:
Stage changes — add them to the index ahead of a commit:
Git’s middle area is the staging area (a.k.a. the index). You stage changes with git add, then commit what is staged. This two-step flow lets you craft precise commits.
Staging collocations:
stage changes / stage a file → git add <path>
unstage changes → remove from the index (git restore --staged)
staged vs unstaged → what will / won’t be in the commit
stage a hunk → git add -p for partial staging
Why not the rest? "Load", "queue" and "buffer" are not Git terms. The established verb is stage, paired with the staging area.
2 / 5
You just committed, then immediately spot a typo in the commit message. To fix the most recent commit in place rather than adding a new one, you:
Amend a commit — edit the latest commit in place:
git commit --amend rewrites the most recent commit — you can fix its message or add forgotten staged changes. It replaces the commit with a new one (new hash), so only amend commits you haven’t pushed (or force-push afterwards).
Commit-editing vocabulary:
amend a commit → fix the last commit’s message or contents
write / fix a commit message → the description line(s)
revert a commit → add a new commit that undoes an old one
reset to a commit → move the branch pointer back
Why not the rest?Revert creates a new undo-commit; reset moves the branch pointer; rebase replays many commits. To fix the latest one in place you amend it.
3 / 5
You’re mid-task when an urgent bug comes in. You want to set your unfinished, uncommitted work aside temporarily so you can switch branches cleanly. You:
git stash saves your uncommitted (staged and unstaged) changes onto a stack and reverts the working tree to a clean state. Later you pop or apply the stash to bring the work back.
Stash collocations:
stash changes → shelve WIP (git stash push)
pop the stash → reapply and remove it (git stash pop)
apply a stash → reapply but keep it on the stack
stash list / drop a stash → view or delete entries
Why not the rest? Although developers loosely say "shelve" or "park" work in conversation, the actual Git verb — and the only correct single word here — is stash. "Freeze" and "shelve-commit" are not Git operations.
4 / 5
A reviewer says your edit to a file is wrong and should be thrown away to restore the last committed version. The phrase for abandoning uncommitted edits is to:
Discard changes — throw away uncommitted edits:
To discard changes means to restore a file to its last committed state, abandoning your local edits (git restore <file>, or "Discard changes" in your editor’s source-control panel). The edits are gone — there’s no commit, so they can’t be recovered from history.
Working-tree vocabulary:
working tree / working directory → your actual files on disk
discard changes → revert files to the committed version
clean working tree → no uncommitted changes
dirty working tree → has uncommitted changes
Why not the rest? "Roll back" usually refers to deployments or migrations; "delete" applies to files, not edits; "cancel" isn’t a Git term. For uncommitted edits the verb is discard.
5 / 5
During review someone writes: "Good change, but your ___ just says ‘fix’ — please make it descriptive."
What are they asking you to improve?
Commit message — the human-readable description of a commit:
A commit message explains what changed and why. Convention: a short imperative subject line (≤50 chars), a blank line, then a body. Many teams follow Conventional Commits (feat:, fix:, docs:).
Commit-message collocations:
write / craft a commit message → describe the change
subject line / commit body → the two parts
imperative mood → "Add", "Fix", not "Added"/"Fixed"
amend the message → fix it after committing
Why not the rest? The commit hash is the auto-generated SHA id; the author is who wrote it; a tag labels a release. Only the commit message is the prose you write — and the thing a reviewer asks you to make descriptive.