Express course · No. 17
Git records every version of your project and lets a whole team change the same files without overwriting each other. Almost all of the fear around it comes from unfamiliar words — commit, branch, rebase — not from real difficulty. Learn the handful of terms and Git turns from a source of dread into the calmest safety net you'll ever have.
21 concepts · a diagram for each · cheat sheet at the end
Before the commands, the problem. Once you feel the pain version control removes, every feature of Git reads as an obvious answer instead of arbitrary jargon.
The map: 21 concepts in six groups
A subway map: first you see the whole set of lines, then you ride station by station.
First the basics — what version control, Git, and a repository are. Then one chapter per group: the commit (how a snapshot is saved), branches (parallel lines of work), merging and conflicts, remotes and teamwork, and history with safe undo. The last chapter covers good habits, a relations map, and the cheat sheet.
How to read each concept
A passport: the same fields for everyone, so they're easy to compare.
Every concept from here on has the same parts: its English name (remember it — it's the term you'll search docs and Git errors for), a picture from everyday life, a diagram, and a card: what it is, how it works, an example (often with a command), the catch, and how it's related to other concepts. At the end: a relations map and a cheat sheet.
Version Control — instead of a folder of _final_v2_FINAL files
A desk buried in report.doc, report_v2.doc, report_final.doc, report_final_FINAL.doc — nobody sure which is current, and the good version from Tuesday lost forever.
Everyone has lived the manual way of keeping versions: copy the file, add a suffix, hope. It collapses instantly — you can't tell which is newest, you can't get back the version you overwrote, and two people editing means one loses work. Version control is the tool built to stop this: one project, its whole history stored safely, and every version restorable.
- Problem
Suffixed copies: no idea which is newest, the old one is gone, two people overwrite each other.
- Idea
One project + a full history of changes, where any version can be restored.
- Example
Instead of
report_final_FINAL.doc— onereport.docand a record of every version of it.- Catch
- It only works if you save changes into the system, not around it.
- Related
Git is the most popular version control system. It keeps the history in a Repository.
Git — a timeline of snapshots
A camera that photographs your entire project every time you say "save this" — so you can flip back to how everything looked at any past moment.
Git is the version control system almost everyone uses. It records your project as a series of snapshots — each one a complete picture of all your files at a moment you chose to save. The result is a timeline you can travel: see what changed, when, and by whom, and go back to any earlier state. It's a save button that never forgets a single save.
- What it is
- The most widely used version control system.
- How it works
Stores the project as a timeline of snapshots of all files at moments you choose.
- Example
Snapshot 3 added
style.css; a month later you can go back to exactly snapshot 2.- Catch
It scares people with words, not difficulty: the terms just need learning.
- Related
Each snapshot is a Commit; the timeline lives in a Repository.
Repository — the project plus its whole history
A book that carries every draft it has ever been, bound into the back — you hold the current text and the full record of how it got that way, together.
A repository (or repo) is your project folder once Git is tracking it: the current files plus the hidden history of every snapshot ever taken (it lives in a hidden .git folder). Clone a repo and you get not just today's code but the entire history. It's the unit you work in — a repo is "a project Git remembers," and everything else in this course is something you do inside one.
- What it is
- A project folder that Git watches: files + the whole history.
- How it works
History lives in the hidden
.gitfolder; the working files are what you see right now.- Example
git initturns a folder into a repo;git clonecopies someone's repo whole, history included.- Catch
- Delete
.gitand only the files remain — the whole history is gone. - Related
Made of Commits; comes as local (yours) and remote (on a server).
Version control replaces the folder of _final_FINAL copies with one project and a complete, recoverable history. Git keeps that history as a timeline of snapshots.
The single most important word in Git is the commit — one saved snapshot on the timeline. Understand how a commit is made and you understand the heartbeat of the whole system.
Commit — one saved snapshot
A photograph of your whole project at a chosen instant, stapled to a note about what that moment was — pinned permanently to the timeline.
A commit is one snapshot in your project's history: a recorded state of the files, with a unique ID (a hash like e81f53) and a note. Every commit points back to the one before it — its parent — forming a chain that is your history. You don't commit constantly but at meaningful points — "added login," "fixed the date bug" — so the timeline reads as a sequence of deliberate steps, each one a place you can return to.
- What it is
One saved snapshot of the project with an ID, author, time, and message.
- How it works
Each commit points to its parent; the chain of parents is the history.
- Example
git commit -m "fix date bug"creates commite81f53.- Catch
A commit saves only what you put in the staging area, not every edit you made.
- Related
Assembled in the Staging Area, labelled by the Commit Message, the latest one marked by HEAD.
Staging Area — pack the box before you seal it
A shipping box on your desk: you place exactly the items for this delivery into it, leaving others aside, and only then tape it shut and send it.
Git doesn't snapshot everything you changed automatically. First you choose which changes go into the next commit by staging them (git add) — putting them in the staging area, the box you're packing. Then git commit seals exactly that box. This two-step — stage what belongs together, then commit — is why Git history can be clean: you decide exactly what each snapshot contains, instead of dumping every change at once.
- What it is
- An in-between "box" between your edits and a commit.
- How it works
git addputs changes in the box,git commitseals it into a snapshot.- Example
Edited
login.js,login.css, andnotes.txt— staged only the first two, committed "add login".- Catch
- Forget
git addand the change won't make it into the commit. - Related
Filled from your working files, emptied into a Commit. The basis of small commits.
Commit Message — a note to the future
Labelling that sealed box with what's inside — so months later someone scanning the shelf knows what each holds without opening it.
Every commit carries a commit message explaining what changed and why. It feels like a chore, but it's pure gold later: when you're hunting the change that broke something, or understanding why a line exists, the messages are the project's story. A good message ("fix timezone bug in invoice export") turns history from a wall of cryptic IDs into a readable log. Write them for whoever reads them in six months — usually you.
- What it is
- A short note on a commit: what changed and why.
- How it works
Written with
git commit -m "…"; later shown in the log next to every snapshot.- Example
- Bad: "fix", "wip". Good: "fix timezone bug in invoice export".
- Catch
- Saving five seconds now costs hours of digging six months later.
- Related
- Labels a Commit; makes the Log readable.
HEAD — your you-are-here marker
The "you are here" dot on the timeline map — it marks which snapshot you're currently standing on.
HEAD is Git's pointer to where you are right now in history — usually the latest commit on your current branch. When you make a new commit, it's added right after HEAD, and HEAD moves forward to it. You rarely touch HEAD directly, but the word appears everywhere, and knowing it simply means "my current position on the timeline" demystifies most of what you'll read.
- What it is
- A pointer to the commit (usually via a branch) where you stand.
- How it works
- A new commit goes right after HEAD, and HEAD moves onto it.
- Example
HEAD → main → c4: you're on main, at commit c4. Commit — now you're on the new one.- Catch
The word looks scary in Git's messages but just means "current position".
- Related
- Moves with every Commit; Switch moves it to another branch.
A commit is one saved snapshot. You stage the exact changes that belong together, then seal them with a message — and HEAD marks where you stand.
Branches are where Git stops being a fancy save button and becomes a way for many people — or many ideas — to move at once without stepping on each other.
Branch — a parallel line of work
Photocopying a manuscript so you can scribble a bold rewrite on your copy, while the original stays clean and others keep working on it.
A branch is an independent line of development: your own copy of the timeline where you can make commits without affecting anyone else's work. You create a branch to build a feature or try an idea, commit freely on it, and the main version stays untouched until you're ready. Branching is how a team works on ten things at once in one repo without chaos: everyone on their own line.
- What it is
- An independent line of commits inside one repo.
- How it works
A branch is just a movable label on the latest commit of a line; new commits move it forward.
- Example
git switch -c feature/login— create a branch for the login form and move onto it.- Catch
- A branch that lives too long drifts from main and merges painfully.
- Related
Leaves main, comes back via Merge or Rebase, gets discussed in a Pull Request.
main — the trusted line
The official, shelved edition of a book that everyone trusts — drafts happen elsewhere, and only finished, approved work gets bound into it.
By convention, the primary branch is called main (older repos may call it master). It holds the stable, working version of the project — the one you'd ship. New work happens on other branches and joins main only once it's ready and reviewed. Treating main as the trusted line, never a scratchpad, is the simple discipline behind most healthy team workflows.
- What it is
- The primary branch, holding the shippable, working version.
- How it works
Nobody writes to it directly; work arrives from other branches via a merge after review.
- Example
The
feature/searchandfix/datebranches merge into main when ready.- Catch
- Committing straight to main risks breaking what everyone relies on.
- Related
Takes work via Merge and Pull Request; every Branch starts from it.
Switch (checkout) — switching branches changes your files
Swapping which draft is open on your desk — the same desk, but now showing a completely different version of the work, instantly.
When you switch to a branch (git switch, formerly git checkout), Git changes the files in your folder to match that branch's snapshot. Move to your feature branch and your edits appear; switch back to main and they vanish from view (safely stored, not lost). Branches in Git are cheap and instant, so making one per feature or fix is normal: not a heavy act, an everyday move.
- What it is
- The command that moves you onto another branch.
- How it works
Git rewrites the files in your folder to that branch's snapshot and moves HEAD there.
- Example
git switch feature/login—login.jsappears;git switch main— it's hidden, but safe.- Catch
- Uncommitted edits can block a switch — commit them first.
- Related
- Moves HEAD between Branches.
A branch is a parallel line of work where you commit freely without disturbing anyone. main is the trusted version; new work lives on its own branch until it's ready.
Work that split onto branches eventually has to come back together. Merging is how Git reunites lines of work, and a conflict is the one moment it needs you to decide.
Merge — bringing two branches back together
Folding the edits from your separate draft back into the official manuscript, so the book now contains both the original and your new chapter.
A merge combines the commits from one branch into another — usually folding a finished feature branch back into main. Git looks at what changed on each side and weaves them into a single timeline that contains both sets of work, often via a merge commit — a commit with two parents. Most of the time this is automatic and effortless: the two branches touched different files or different parts, and Git simply stitches them together.
- What it is
- Combining the work of one branch into another.
- How it works
Git compares both sides' changes and creates a merge commit with two parents.
- Example
git switch main→git merge feature/login— the login form is now in main.- Catch
If both sides touched the same line you get a conflict, and you decide.
- Related
The alternative is Rebase. Can lead to a Merge Conflict. On teams it goes through a Pull Request.
Merge Conflict — two edits to the same line
Two editors who each rewrote the exact same sentence differently — no machine can know which you meant, so it stops and asks you.
A merge conflict happens when both branches changed the same part of the same file in incompatible ways. Git can't guess which version is right, so it pauses, marks the spot, and shows you both versions side by side. This isn't an error or a disaster — it's Git correctly refusing to silently throw away someone's work. Conflicts feel scary the first time precisely because the stakes (not losing work) are clear.
- What it is
- Two branches changed the same spot in a file differently.
- How it works
- Git stops the merge and marks the disputed lines in the file.
- Example
- Line 3 of
greeting.txt: "Hello, team!" versus "Hi, world!". - Catch
- It's not breakage — it's Git refusing to silently drop someone's work.
- Related
Arises during Merge or Rebase; fixed by Conflict Resolution; rarer with short branches.
Conflict Resolution — resolving a conflict is just choosing
Reading both rewritten sentences, then writing the final version you actually want — keeping one, the other, or a blend — and moving on.
You resolve a conflict by editing the marked file to the version you want — keep yours, keep theirs, or combine them — removing the <<<<<<<, =======, >>>>>>> markers, then committing the result. That's the whole secret: a conflict is Git handing you a decision only a human can make, and resolving is making that decision. Conflicts get smaller and rarer when branches are short-lived and you merge often, so the two sides never drift far apart.
- What it is
- Manually choosing the final version of a disputed spot.
- How it works
Edit the file, remove the
<<<<<<</=======/>>>>>>>markers, thengit addandgit commit.- Example
- "Hello, team!" and "Hi, world!" became "Hi, team!".
- Catch
- To choose well you must understand both versions — ask the author if unsure.
- Related
- Completes a Merge after a Merge Conflict.
Merging weaves two branches into one timeline. A conflict is just two edits to the same line — Git refusing to guess, and asking you to choose.
So far everything lives on your machine. Working with others — or backing up your work — means connecting your local repo to a shared one in the cloud.
Local and Remote — two copies, origin is the shared one
Your personal working copy of the manuscript at home, and the shared master copy at the office that the whole team keeps in sync with.
Git is distributed: you have a full copy of the repo on your machine (local), and usually there's a shared copy on a server (remote) — on a service like GitHub or GitLab. You do all your work locally — fast, even offline — and sync with the remote to share it and pull in others' work. The default remote is conventionally named origin. Two copies, deliberately kept in step.
- What it is
Local is your full copy of the repo; remote is the shared copy on a server. The main remote is called origin.
- How it works
- Work locally (even offline), then sync with the remote.
- Example
The repo on GitHub is origin; you and your teammates each have a copy on a laptop.
- Catch
- Work you haven't pushed lives only on your laptop — and dies with it.
- Related
The copies are synced by Clone / Push / Pull / Fetch; Pull Requests live on the remote.
Clone, Push, Pull, Fetch — the four sync moves
Photocopying the office master to take home (clone), sending your finished pages back (push), and collecting everyone else's new pages (pull).
Four words move work between local and remote. Clone makes your first local copy of a remote repo. Push sends your commits up to the remote so others can see them. Pull brings others' new commits down into your copy and merges them. Fetch downloads what's new without merging it yet, so you can look first. Master these four and you can collaborate: they're the whole vocabulary of staying in sync.
- Clone
git clone <url>— your first full local copy of a remote repo.- Push
git push— send your commits to the remote.- Pull
git pull— download others' commits and merge them in (fetch + merge).- Fetch
git fetch— download what's new but don't merge yet: look first.- Catch
A push without a pull is often rejected: bring in others' changes first, then send yours.
- Related
Move Commits between Local and Remote; pull does a Merge inside.
Pull Request — how teams review work
Submitting your new chapter to editors who read it, comment, and approve it before it's bound into the official book.
On platforms like GitHub, you usually don't merge straight into main. You push your branch and open a pull request (PR; on GitLab, a merge request) — a proposal to merge your work, where teammates review it, leave comments, and approve before it joins main. It's the checkpoint where a second pair of eyes catches problems and the team agrees a change is ready. The PR is where most team Git actually happens.
- What it is
A proposal to merge a branch into main, with discussion and review.
- How it works
Push the branch → open a PR → comments and fixes → approval → merge.
- Example
PR "add login form": a teammate asks to rename a function, you push the fix, the PR is approved.
- Catch
- Nobody really reads a giant PR — keep them small.
- Related
Lives on the Remote, carries a Branch, ends in a Merge into main.
Local is your copy; remote (origin) is the shared one. Clone, push, pull, and fetch keep them in step — and a pull request is where the team reviews before merging.
Git's deepest comfort is that almost nothing is ever truly lost. Knowing how to read history and step back safely is what turns Git from frightening into reassuring.
Log — the story of the project
Flipping through a dated, signed stack of every draft — seeing exactly what changed at each step and who did it.
The log (git log) is the list of commits, your project's history in order, each with its message, author, and time. It answers "what happened, and when?" and it's the starting point for understanding any codebase or hunting any bug. When something breaks, the log lets you find the exact commit that introduced it, because every change is recorded. A history you can read is a history you can debug.
- What it is
- The list of every commit: ID, author, time, message.
- How it works
git logshows the history from newest commits to oldest.- Example
Dates broke on June 11 — the log shows commit
e81f53"change date parsing".- Catch
- The log is only as useful as the commit messages in it.
- Related
Reads the chain of Commits; its value comes from the Commit Message.
Revert vs Reset — two undos: the honest one and the rewriting one
Two ways to undo a mistake: add a clearly marked correction to the record (revert), or quietly tear out the last page as if it never happened (reset).
Git gives you safe ways back. Revert creates a new commit that undoes an earlier one — the mistake stays in history, with its undo recorded on top, which is honest and safe for shared work. Reset moves you back to an earlier commit, rewriting recent history as if those commits never happened — powerful, but dangerous on work others already have. Rule of thumb: revert on anything public, reset only on private, local work.
- Revert
git revert C— a new commit that undoes C. History stays intact.- Reset
git reset B— move the branch back to B, as if C never happened.- Example
Broke prod with a commit on main — revert. Messed up locally, never pushed — reset.
- Catch
Resetting what teammates already pulled throws the whole team out of sync.
- Related
Work on Commits and HEAD; reset, like Rebase, rewrites history.
Rebase — replays your work; respect the golden rule
Instead of stapling your side draft onto the manuscript with a visible seam (merge), you rewrite your edits cleanly on top of the latest version, as if you'd started from it (rebase).
Rebase is an alternative to merge: instead of joining two lines with a merge commit, it replays your commits on top of another branch, producing a tidy, straight-line history. It's great for cleaning up your own branch before sharing it. But it rewrites commits (it creates new copies of them), so the golden rule: never rebase history that others have already pulled. Rewrite shared history and you throw everyone out of sync. Rebase your private work; merge to combine shared work.
- What it is
- Replaying your commits on top of another branch.
- How it works
Git takes your commits and recreates copies of them on the new base.
- Example
On
feature, rungit rebase main— your X and Y now sit after the fresh C from main.- Catch
- Golden rule: never rebase history that others have already pulled.
- Related
The alternative to Merge; can cause a Merge Conflict; rewrites history, like Reset.
The log is the readable story; revert and reset are your ways back. Rebase makes tidy history — but never rewrite history others have already pulled.
Git has many commands, but good practice is a short list of habits. Follow them and Git stays a calm safety net instead of an occasional crisis.
Small Commits — small, focused commits
A photo album where each picture captures one clear moment with a caption — far more useful than one blurry shot of everything at once.
Commit small and often (small, atomic commits), so each commit is one coherent change with a message that explains it. Tiny, well-labelled commits make history readable, bugs easy to trace, and undos surgical: you can revert one precise change without losing anything else. A giant commit dumping a week of mixed work is the opposite — impossible to review, untangle, or partly undo. The discipline costs seconds and pays off for the life of the project.
- Problem
- A giant commit can't be reviewed, untangled, or partly undone.
- Idea
- One commit = one coherent change + a clear message.
- Example
Instead of "week of work" — "add login form", "style login page", "fix date bug".
- Cost
- A few seconds to
git addthe right files and write the message. - Related
Rests on the Staging Area and Commit Message; makes Revert and the Log useful.
Feature Branch Workflow — a branch per feature, merged often
Each new chapter drafted on its own copy and folded back in while it's still small — so no draft ever drifts so far from the book that reuniting it becomes a battle.
Do each piece of work on its own branch (a feature branch), keep it short-lived, and merge it back often. Long-lived branches drift far from main and turn merging into a painful pile of conflicts; small branches merged frequently stay easy. Pair it with pull before you push — bring in others' changes first — so you integrate continuously instead of colliding at the end. This rhythm is the heart of smooth team Git.
- Problem
Everyone writes to main — they break each other; one long branch — a mountain of conflicts at the end.
- Idea
- One task — one short branch, merged through a PR in days, not weeks.
- Example
fix/date: pull, branch, two commits, push, PR, review, merge — all in a day.- Cost
- You have to cut work into small pieces and pull main often.
- Related
Ties together Branch, Pull, Push, Pull Request, and Merge.
How the concepts connect
An assembly line: from an edit in a file to the trusted version — one road with clear stops.
The whole road looks like this. Edits in your working files go via git add into the staging area, and via git commit into a commit, which you read in the log. Commits build up on branches; branches come back via merge or rebase, sometimes with a conflict. On a team, you push the branch to the remote, open a pull request, and after review merge into main. If something goes wrong — revert or reset.
- Pull the latest before you start, so you build on current work.
- Work on a branch, never directly on fragile main.
- Make small commits with clear messages as you go.
- Merge often, while branches are still short, to keep conflicts tiny.
- Push your work and open a pull request for review.
- Undo with revert on shared work; never rebase history others have.
- Your history reads like a clear story of small, labelled steps.
- New work lives on branches; main always works.
- You pull before you push and merge while branches are still small.
- You reach for revert on shared work and never rewrite shared history.
- Git feels like a safety net — you experiment freely, knowing you can always get back.
Good Git is a few habits: pull first, branch your work, commit small with clear messages, merge often, and review before you merge. The commands are many; the discipline is short.
Cheat sheet: all 21 concepts
Basics
- Version ControlVCS
One project + a full history; any version can come back.
- Gita timeline of snapshots
The most popular version control system; stores the project as snapshots.
- Repositoryrepo
Project folder + hidden history in
.git.
The commit
- Commitsnapshot
One saved snapshot with an ID and a link to its parent.
- Staging Areathe index
The box before a commit:
git addfills it,git commitseals it.- Commit Messagethe note
A note to the future: what changed and why.
- HEADyou are here
Pointer to the current commit; moves forward with every commit.
Branches
- Branchline of work
A parallel line of commits that doesn't touch anyone else's work.
- mainprimary branch (master)
The trusted, always-working version.
- Switch / Checkoutchanging branches
Move onto a branch: the folder's files change to its snapshot.
Merging and conflicts
- Mergejoining
Bring branches together; often via a commit with two parents.
- Merge Conflictconflict
Two branches edited the same line differently; Git asks you to decide.
- Conflict Resolutionresolving
Choose the final version, remove the markers, commit.
Remotes and the team
- Local / Remoteorigin
Your full copy and the shared copy on a server.
- Clone / Push / Pull / Fetchsyncing
First copy · send yours · bring theirs and merge · download only.
- Pull RequestPR, review
A proposal to merge a branch into main after review.
Undo and history
- Loghistory
The list of commits: who, when, what, and why.
- Revert vs Resetundo
Revert — a new undo commit (for shared work). Reset — rewrite (only your own).
- Rebasereplaying
Replay commits on top of another branch. Never on shared history.
Good habits
- Small Commitsatomic commits
One change — one commit with a clear message.
- Feature Branch Workflowa branch per feature
A short branch per task, merged often through a PR.