Build Git Intuition from Scratch
A story-first walkthrough of commits, branches, and remotes without jargon or memorized commands.
Think of Git as the running history of a project. Instead of remembering vague definitions, picture yourself writing a novel called Coffee Wars and saving different drafts as you explore the plot.
Stage 1: Local History
You begin with a blank document. After the first writing session you save a file named v1.txt that says “A barista enters a latte art competition.” The next day you revise it to “A barista named Luna enters a latte art competition.” Later you try a third version where “Luna wins the championship but realizes something deeper.”
Those saved drafts line up exactly with Git commits. Each commit is a recorded snapshot of the entire project. The newest snapshot sits on your default storyline, a branch Git calls main. When you run commands like:
git add story.txt
git commit -m "First version"
Git captures the exact state of every tracked file so you can refer to that moment forever.
Stage 2: Parallel Experiments
Now you want to explore a darker ending where Luna loses. Rather than overwriting your main storyline, you create an alternate timeline. In Git that is a branch:
git branch dark-ending
git switch dark-ending
Any edits you commit now live only in this new universe. Maybe the draft ends with “Luna loses but opens her own café.” Your original main branch still describes her victory. Git simply keeps both outcomes in parallel.
Stage 3: Following the Bookmark
How does Git know which timeline you are editing? It uses a pointer named HEAD. Think of HEAD as the bookmark in your manuscript—the sticky note that says “we are currently reading the dark-ending version.” Switching branches just moves the bookmark:
HEAD → dark-endingwhen you explore the lossHEAD → mainwhen you return to the original arc
Nothing mystical is happening; Git is just pointing at a different saved draft.
Stage 4: Merging Storylines
Suppose you decide the darker twist belongs in the main book. From the original storyline you merge in the darker branch:
git switch main
git merge dark-ending
Git brings the two drafts together. If both versions changed the same sentence, Git pauses and asks you to choose the final wording—that is a merge conflict. You edit the sentence once, save, and Git records a new commit that now contains the best of both branches.
Stage 5: Sharing With Others
Eventually you want feedback, so you upload the project to GitHub. Your laptop holds the local branch main; GitHub stores a copy called origin/main. Pushing sends your latest commits to the shared copy:
git push origin main
Teammates pull changes back down, make their own branches, experiment, and merge just as you did. Everyone sees the same stack of drafts because Git synchronizes the snapshots across machines.
That is the whole mental model: commits are drafts, branches are alternate timelines, HEAD is your bookmark, merges stitch timelines back together, and remotes are shelves where you and your teammates store and share the latest version of the story.