Loading articles
Learning path
Git from fundamentals and internals to branching, interactive rebase, undoing mistakes, hooks, and team workflows.
A folder named final_v2_ACTUAL_fixed_USE_THIS is what version control looks like when nobody's using version control. Understanding what init, add, and commit actually do — and why a staging area exists at all — is the difference between typing commands and using the tool.
Read chapter →
Two branches merge instantly nine times out of ten, then one day Git stops and asks you to resolve a conflict by hand. Understanding what a branch actually is — a movable pointer, not a copy of the project — explains both cases from the same underlying mechanism.
Read chapter →
A pull request with fourteen commits named "wip", "fix", and "actually fix" tells a reviewer nothing about what changed or why. Interactive rebase turns that into a small number of meaningful commits — as long as you know the one rule about which commits are safe to rewrite.
Read chapter →
Git has four different ways to undo something, and they are not interchangeable. Using the wrong one is how "undo my last commit" turns into "where did my work go" — understanding what each command actually moves (working directory, staging area, or history) fixes that.
Read chapter →
A "lost" commit after a bad reset or force-push is almost never actually gone. git reflog keeps a local record of everywhere HEAD has pointed, bisect turns "somewhere in these 200 commits" into a 10-second binary search, and blame turns "who wrote this" into an actual answer.
Read chapter →
Fetch and pull look interchangeable until the day pull silently creates a merge commit you weren't expecting. Understanding what a remote-tracking branch actually is explains the difference, and sets up how forking, upstream, and pull requests fit together.
Read chapter →