Version control is a safety net
Not a filing system — an undo button for your entire project, and the only reason it's safe to try things.
- You can save work in small commits and explain why that makes everything else easier.
- You can recover from the four common git mistakes without panic or a fresh clone.
Git's reputation for being difficult comes from learning commands by memorisation. The mental model is simpler than the command list: a commit is a labeled snapshot of the whole project, and a branch is a movable label pointing at one of those snapshots. Everything else — merging, rebasing, pull requests — is bookkeeping over that idea.
Once you trust it, your behavior changes in a useful way. You try the risky refactor because you can throw it away. You commit every twenty minutes because a commit is cheap. You review your own diff before anyone else sees it, because the diff is the story of what you just did.
3.1Commits, in three rules
- Small. One logical change per commit. If the message needs "and", it's probably two commits.
- Frequent. Every working milestone — not every keystroke. Twenty minutes of green tests is a savepoint.
- Described. First line: what changed, imperative mood ("fix rounding on refunds"). Body: why, and what you considered. Six months from now the "why" is the valuable part.
# what a useful commit looks like
fix: round refund totals to cents, not floats
Totals were summed as binary floats, so refunds showed
12.999999999 instead of 13.00. Money math now uses integer
cents, with a regression test for the reported case.
Refs: TICKET-412Read your first line out loud. If it would make sense in a changelog that a stranger reads, it's good. "update stuff", "fix", "wip" fail that test — and they are what you'll be reading at 2am when you're looking for the change that broke production.
3.2The four panics, and the way out
Uncommitted changes you want gone. Nothing was saved, so nothing is lost.
git diff # see what you'd lose
git restore path/to/file # discard changes in that file
git restore . # discard everything unstagedIf you're not sure, git stash first — it puts the changes in a drawer you can reopen with git stash pop.
You just committed with a typo, or forgot a file. Nothing has been shared yet.
git add forgotten-file
git commit --amend # rewrites the last commit; opens the message editorSafe only while the commit is unpushed — amending changes its identity, which rewrites history for anyone who already has it.
You committed to main instead of a branch. Move the commit, don't retype the work.
git branch feature/my-change # label where you are
git reset --hard origin/main # put main back where the server is
git switch feature/my-change # your work is on the branchThe commit is not deleted — the branch label is still pointing at it. That is the whole trick.
You pushed a bad commit to a shared branch. Do not rewrite history. Add a commit that undoes it.
git revert <sha> # creates a new commit that reverses that one
git pushReverting is honest and safe: everyone else's clone still makes sense. Force-pushing a shared branch is how teams lose a day.
A single "initial commit" with 40 files means no history, no bisect, no useful review, and no clean revert. Commit early, commit small, and never commit a secret — once a key is in history, treat it as leaked and rotate it, even if you delete the file afterwards.
You pushed a broken commit to main, and two colleagues have already pulled it. What now?
60-second recap
- A commit is a snapshot; a branch is a label. Once you believe that, git stops being scary.
- Small, frequent, described. The message is for the person debugging at 2am.
- Nothing is permanent until it's pushed and shared — and even then, revert is the tool.
- Never force-push a shared branch; never commit a secret.