Intuition The One Core Idea
Git is a machine that takes photographs of your project folder and lines those photographs up on a timeline, so you can always walk back to any earlier photo. Everything else — commits, branches, staging, pushing — is just names for taking a photo , labelling a photo , or sharing the album with other people.
Before you touch a single command in the parent note , you need to know what every word and symbol on that page actually means . This page assumes you have never seen Git. We build each idea from a picture, then say why the topic needs it. We introduce the commands (git init, git add, git commit, …) only after the idea each one acts on is on the table — never before.
Definition Directory / Folder
A directory is just a folder on your computer that holds files. When we say "your project", we mean one folder with your code, notes, and data inside it.
Picture: a labelled box holding sheets of paper (your files).
Why the topic needs it: Git watches exactly one folder and everything inside it. Nothing outside that folder exists to Git.
To even tell Git which folder to watch, you type instructions at a text prompt — the command line . For now just know that a Git instruction is a short line of text you type there; we will explain each specific instruction the moment its underlying idea has been defined, and never sooner.
Look at the figure. The big box is your working directory — the files you can see and edit right now. The small shaded box inside it labelled .git is Git's private album of photographs. You never edit .git by hand; Git fills it as you work.
.git folder
==.git== is a hidden sub-folder Git creates inside your project. It stores the entire history — every photograph ever taken. The dot at the front means "hidden" so it doesn't clutter your normal file view.
Picture: a locked drawer inside the box, full of dated photographs.
Why the topic needs it: this drawer is what makes "time travel" possible. Delete .git and you delete all history, keeping only the current files.
Definition Repository (Repo)
A repository is the whole package: your working directory plus its .git drawer. When the parent says "repo", it means "a folder that Git is watching".
Picture: the entire box (visible papers + the history drawer).
Why the topic needs it: an ordinary directory is just the visible papers — it has no memory. The word "repository" marks the difference: a folder that has grown a history drawer and is now under Git's watch. Every command in the parent only works inside a repository, so knowing whether a folder is a plain directory or a repo tells you whether Git can do anything at all.
Now the central word of the whole topic.
A commit is one photograph — a saved snapshot of every tracked file at one moment. Once taken, that photo never changes.
Picture: a single dated Polaroid of your whole folder.
Why the topic needs it: the timeline is made of commits. "Going back in time" means "look at an older commit". Without commits there is no history at all.
Each commit carries a small label so you can find it again:
A hash is a long ID string like a3f2e1b... that Git computes for each commit. It is a fingerprint: change even one letter of one file and the fingerprint changes completely.
Picture: a unique serial number stamped on the back of each Polaroid.
Why the topic needs it: commits have no human names, so Git points to them by hash. When the parent writes e7f3a2c, that is one commit's fingerprint (shortened to the first 7 characters — enough to be unique in a small project).
Intuition Why a fingerprint and not "commit #1, #2, #3"?
Numbers would break the moment two people commit at the same time on different computers — whose commit is "#5"? A fingerprint computed from the content is guaranteed unique no matter who made it or when. That is why Git chose hashing.
Each commit remembers which commit came just before it — its parent . Follow the parents backwards and you walk the whole history.
Picture: each Polaroid has a string tied to the one before it, forming a chain.
Why the topic needs it: this chain is the timeline. A "merge commit" (parent note, three-way merge) is special because it has two parent strings — it joins two chains back together.
In the figure, each amber circle is a commit and each arrow points from a commit back to its parent . Read the arrows right-to-left to travel back in time.
The parent's most important diagram is "the three states". Here is what each really means, as three rooms a file passes through on its way into a photograph.
Definition Staged (Staging Area / Index)
A file is staged when you have picked it to appear in the next photograph. The staging area is also called the index .
Picture: papers you've placed on the photo table, arranged, ready for the camera.
Why a middle room at all? So you can photograph some changes and not others. This lets you group related edits into one clean commit — the parent calls these atomic commits .
The two arrows between the rooms are the two most-used commands. Read the figure as a doorway diagram: a change walks from the desk (Modified) onto the photo table (Staged) through the door called git add, then into the drawer (Committed) through the door called git commit.
Intuition The two doorways
git add = "put this paper on the photo table" — moves a change from Modified to Staged .
git commit = "take the photo and file it" — moves everything staged into Committed .
And the very first command, git init, is simply "grow a .git drawer on this folder" — turning a plain directory into a repository.
A branch is a sticky label attached to one commit. As you make new commits, the label automatically slides forward to the newest one.
Picture: a bookmark clipped onto the newest Polaroid in a chain.
Why the topic needs it: it lets you grow a second chain of photos (a "feature branch") without disturbing the first, so experiments can't break working code.
The parent notes a branch is only ~41 bytes — because it stores just one hash (a 40-character fingerprint) plus a newline. A label, not a copy.
A tag is a fixed label pinned to one specific commit — and unlike a branch it does not slide forward when you make new commits.
Picture: a permanent "v1.0" sticker stuck to one Polaroid; you can add new Polaroids to the chain but the sticker stays exactly where you put it.
Why the topic needs it: branches answer "where is work happening now ?"; tags answer "which exact photo was our release / trained model?". That is why tags are how a project marks versions — the same idea powers model versioning , where each shipped model is pinned to one tagged commit.
Common mistake Branch vs tag
A branch moves (it tracks the tip of ongoing work). A tag stays put (it marks a moment forever). Using a branch where you meant a tag means your "release marker" quietly drifts to new commits.
main / master
==main== is simply the name of the default branch label Git makes for you. Older projects call it master; they mean the same thing.
HEAD is a special pointer meaning "the branch you are on right now". New photos get filed under whatever HEAD points to.
Picture: a "YOU ARE HERE" arrow resting on one bookmark.
Why the topic needs it: the parent's log output shows (HEAD -> main) — this literally means "you are currently on the main branch". Whenever you move between branches, it is this arrow that gets moved.
Moving that arrow needs a command — and now that we know what the arrow is , we can name it:
git checkout
==git checkout== is the command that moves the HEAD arrow to a different branch (or a specific commit).
Picture: picking up the "YOU ARE HERE" arrow and dropping it onto a different bookmark.
Why the topic needs it: to work on another branch you must first be on it — checkout is how you get there, so the next photo you take joins that branch's chain.
The figure shows two branch labels (main and feature) clipped to different commits, with the amber HEAD arrow resting on feature — telling you the next photo joins the feature chain.
Usually HEAD points at a branch label , which in turn points at a commit. But you can also make HEAD point directly at a commit with no branch in between — this is a detached HEAD .
Picture: the "YOU ARE HERE" arrow resting straight on a Polaroid instead of on a bookmark.
Why it matters: in this state any new commit you make has no branch label following it . Move HEAD away and that commit has no bookmark pointing to it — it can be lost, because Git finds commits by following labels. This is exactly what happens when you git checkout an old commit by its hash to "look around". To keep new work, attach a branch (or tag) before leaving.
Intuition The full pointer chain
Normal: HEAD → branch → commit. Detached: HEAD → commit. Knowing which one you are in explains where your next commit will land and whether it is safe .
Intuition Merge as an equation of ideas
Think of a three-way merge as: find the common ancestor (the last photo both chains shared) + apply both sets of changes on top of it. Git only needs the ancestor to know what each side started from , so it can tell what each side changed .
Common mistake Merge conflicts — the edge case you must know
Automatic merging works when the two branches changed different lines. But if both branches edited the same line differently, Git cannot guess which version wins — this is a merge conflict .
Git pauses the merge and marks the clashing spot inside the file with <<<<<<<, =======, >>>>>>> guide lines showing both versions.
What you must do: open the file, delete the guide lines, keep the correct combination by hand, then git add the fixed file and git commit to finish the merge.
Why it can't be automatic: only a human knows which change is meant ; Git refuses to silently throw work away.
A remote is another copy of the repository living on a server (like GitHub ). Your machine and the server each hold a full album.
Picture: a twin box in the cloud with its own copy of the drawer.
Why the topic needs it: everything so far happens only on your computer. To back work up or share it with teammates you need a second album elsewhere — the remote. You cannot understand push, fetch, or pull without first knowing there are two albums that need to be kept in sync.
A URL (e.g. https://github.com/user/repo.git) is the internet address of the remote — where to find the twin box.
Why the topic needs it: a nickname for a remote has to point somewhere ; the URL is that "somewhere". It is what you give once so Git knows which twin box on the internet to talk to.
git clone
==git clone <url>== is the doorway by which you first obtain a repository that already exists on a remote. It copies the entire album — every photograph and label — down to a brand-new folder on your machine.
Picture: photocopying the whole twin box (drawer and all) to make your own local box, then propping the newest photo up on the desk so you can start work.
Why the topic needs it: git init builds an empty repo from scratch; clone is the other starting point — how you join a project that already has history. Because clone copies the full drawer, you get complete backup and can work offline. It also quietly sets up the remote nickname for you.
==origin== is just the conventional nickname for your main remote, so you don't retype the full URL every time. git clone sets this nickname up automatically.
Why the topic needs it: every sync command takes a remote name; origin is the default that name usually is, so git push origin main reads as "push to the remote, branch main".
Intuition The three sync words
Picture two albums, yours and the remote's, that can drift apart:
git push = send your new photos to the remote's album (yours → server).
git fetch = look at the remote's new photos without mixing them in yet (server → yours, no merge).
git pull = fetch and then merge in one step. In other words, git pull is exactly git fetch followed by git merge.
Push = push out (yours → server). Pull = pull in (server → yours). The word tells you the direction.
Read the map below bottom-up toward TOPIC : every box is one foundation from this page, and the arrows show what must be understood before the box it points to. Start at the top-left roots (a folder, the command line) and trace downward — you can see the whole topic literally grows out of "a folder that remembers". Each strand (staging, branching, syncing) arrives at the same destination, the parent note, showing why all four skills are needed together rather than in isolation.
Parent link builds timeline
Three rooms Modified Staged Committed
Merge conflict needs a human
git clone copies the album
Git version control basics
Once these foundations click, the same photographs power notebook versioning , experiment tracking , model versioning , and CI/CD pipelines — but all of that starts with "a folder that remembers".
Test yourself — say the answer out loud before revealing.
What is a repository, in one sentence? Your project folder plus its hidden .git history drawer — a folder Git is watching; a plain directory has no history drawer.
What is a commit? One saved snapshot (photograph) of every tracked file at one moment; it never changes once taken.
Why does Git identify commits by a hash instead of numbering them 1, 2, 3? A content-based fingerprint is guaranteed unique even when many people commit at once on different machines; numbers would collide.
What links commits into a timeline? Each commit stores its parent — the commit before it — forming a chain you follow backwards.
Name the three rooms a file passes through and the command between each. Modified → (git add) → Staged → (git commit) → Committed.
Why does the staging area exist at all? So you can choose which changes go into the next photo, grouping related edits into one clean atomic commit.
What is a branch, physically? A tiny label (~41 bytes) holding one commit's hash; it slides forward automatically as you add commits.
How does a tag differ from a branch? A tag is a fixed label pinned to one commit forever; it does not slide forward — used to mark releases/model versions.
What does HEAD point to, normally, and what command moves it? The branch you are currently on; git checkout moves the HEAD arrow to another branch or commit.
What is a detached HEAD, and why is it risky? HEAD points directly at a commit with no branch in between; new commits there have no label following them, so they can be lost if you move away.
How do you first obtain a repository that already exists on a remote? git clone <url> — it copies the entire album to a new local folder and sets up the origin nickname.
What is a remote, and what is origin? A remote is a full copy of the repo on a server; origin is the conventional nickname for your main one.
What is git pull made of? git fetch followed by git merge.
When is a merge a fast-forward vs a three-way merge? Fast-forward when main did not move (just slide the label); three-way when both branches grew, needing a new commit with two parents.
What is a merge conflict and what must you do? Both branches edited the same line differently, so Git can't choose; you edit the file by hand to keep the right version, then git add and git commit to finish.