5 exercises on Git’s trickiest vocabulary: rebasing onto a base, interactive rebase, squashing, revert vs reset, and safely rewriting history.
Key patterns
rebase onto a base vs merge into a target
interactive rebase → reword / squash / drop
squash commits; cherry-pick a commit
revert (safe, public) vs reset (rewrite, private)
Never rewrite history on a shared branch
0 / 5 completed
1 / 5
Your feature branch started from an old commit on main. You want to replay its commits so they sit on top of the latest main. The standard phrasing uses which preposition?
Rebase onto — replay commits on a new base:
You rebase a branch onto another branch: git rebase main (or explicitly git rebase --onto main) takes your commits and re-applies them on top of main’s latest commit, giving a clean linear history.
Preposition contrast (the classic trap):
rebase ONTO a base → move commits to a new starting point
merge INTO a target → combine branches, possibly a merge commit
rebase conflicts → resolve, then git rebase --continue
force-push after rebasing → history changed, so the remote needs it
Why not the rest? "Rebase into/against/over" are wrong. The fixed pairing is rebase ONTO vs merge INTO.
2 / 5
You run git rebase -i HEAD~5 to open an editor where you can reorder, edit, squash, or drop commits. This mode is called an:
Interactive rebase — edit history through a to-do list:
An interactive rebase (git rebase -i) opens an editor listing the chosen commits with actions you can change: pick, reword, edit, squash, fixup, drop. It’s the main tool for cleaning up a branch before opening a PR.
Interactive-rebase verbs:
squash commits → fold several into one (keeps messages)
fixup a commit → like squash but discard its message
reword → change just a commit message
drop a commit → delete it from history entirely
Why not the rest? Git’s flag is -i for interactive. "Automatic", "incremental" and "inline" rebase are not Git terms.
3 / 5
A merged commit broke production. You want to undo it safely on the shared main branch by adding a new commit that cancels its changes — without rewriting history. You should:
Revert — safe undo via a new commit:
git revert <hash> creates a new commit that inverts a previous one. Because it adds rather than rewrites, it’s the safe choice on shared branches — nobody’s history is broken.
Revert vs reset (a key distinction):
revert a commit → new commit that undoes it; safe to push (public undo)
reset to a commit → moves the branch pointer back, rewriting history; for local/private branches only
soft / mixed / hard reset → how much of the index and working tree is reset
drop a commit → remove it during an interactive rebase (also a rewrite)
Why not the rest?Reset and drop rewrite history (dangerous on shared main); amend only touches the latest commit. For a safe public undo you revert.
4 / 5
A senior dev warns: "Never ___ ___ on a branch other people have already pulled — you’ll force everyone to re-clone."
Which two-word phrase fills the blanks?
Rewrite history — the umbrella term for changing existing commits:
To rewrite history means to alter commits that already exist — via rebase, amend, reset, or filter-repo. On a shared branch this is dangerous: everyone else’s clones diverge, forcing painful re-syncs or re-clones. The golden rule: don’t rewrite public history.
History-rewrite vocabulary:
rewrite history → change existing commits
rewrite the history of a branch → the full collocation
shared / public branch → one others have pulled
force-push → needed to publish a rewrite (use --force-with-lease)
Why not the rest? "Refactor commits", "reset history" and "replace history" aren’t idiomatic. The fixed phrase developers use is rewrite history.
5 / 5
During an interactive rebase you decide one experimental commit should be removed from the branch’s history completely. In the rebase to-do list you change its action from pick to:
Drop a commit — delete it during an interactive rebase:
In the git rebase -i to-do list, replacing pick with drop (or simply deleting that line) removes the commit from the rebuilt branch entirely. It’s how you discard an experiment or a bad commit mid-branch.
Interactive-rebase actions:
pick → keep the commit as-is
reword → keep changes, edit the message
edit → pause to amend the commit’s contents
squash / fixup → fold into the previous commit
drop → remove the commit completely
Why not the rest?squash merges a commit into another (doesn’t delete its changes), edit pauses to modify it, and reword only changes the message. To delete a commit you drop it.