Git Tutorial: Fixing Common Mistakes and Undoing Bad Commits

Undoing mistakes in Git comes down to choosing the right tool for the kind of error—and whether anyone else has already pulled the changes. The most important distinction is between commands that rewrite history (like changing a commit message or moving commits around) and commands that preserve history by adding new “undo” commits. When history rewrite is safe, it keeps the commit graph clean; when it isn’t, Git’s revert workflow avoids breaking other people’s repositories.

The tutorial starts with a simple case: making unwanted edits to a tracked file. After modifying calc.py and confirming the changes with git status and git diff, the fix is to discard local edits using git checkout calc.py. That restores the file to the state from the last commit, returning the working directory to “clean.” From there, the walkthrough moves to commit-level mistakes.

A wrong commit message is corrected immediately with git commit --amend. After creating a commit with an incorrect message (“completed the multiply function” instead of “completed the subtract function”), the amend option opens the commit editor so the message can be replaced without creating a new commit. The tradeoff is explicit: the commit hash changes because the commit content changes, which means Git history is rewritten. The same amend mechanism also works for missing files—creating a .gitignore file, staging it, and then running git commit --amend (without changing the message) folds the new file into the existing last commit. Again, the hash changes, so this approach is only appropriate when the commit hasn’t been pushed or shared.

Next comes the common “wrong branch” problem. Commits accidentally made on master instead of subtract feature are moved by cherry-picking the intended commit onto the correct branch, then resetting master back to the initial commit. cherry-pick creates a new commit on the target branch but leaves the original commit intact on master, so cleanup requires git reset. The tutorial breaks down git reset’s three modes: --soft keeps changes staged, the default mixed reset keeps changes in the working directory, and --hard discards tracked changes entirely. Because --hard leaves untracked files behind, git clean -d -f is used to remove untracked files and directories.

If a hard reset deletes something important, recovery is still possible via git reflog, which records recent references to commits. By checking out the commit hash from before the reset and creating a new branch (e.g., backup), the “lost” work can be preserved before Git garbage-collects unreachable commits.

Finally, when other people already pulled the commits, the safe undo path is git revert. revert creates a new commit that reverses the changes of a specified earlier commit without altering the original commit hashes. The result is an intact history that won’t corrupt collaborators’ checkouts, and git diff between the original and reverted commits shows the changes being undone in the opposite direction.