# Git: a save button with a memory Express course on Git and version control. 21 concepts — Version Control, Repository, Commit, Staging Area, HEAD, Branch, main, Merge, Merge Conflict, Remote and origin, Clone/Push/Pull/Fetch, Pull Request, Log, Revert and Reset, Rebase, and more — each with its English name, a picture, a diagram, and a card with an example. At the end: a relations map and a one-page cheat sheet. The big idea: most of the fear around Git is just unfamiliar words — learn them and it becomes a calm safety net. - **Author:** Fedor Chishchin - **Level:** intro - **Reading time:** ~30 minute read - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/learn/git-express --- ## 1. Why version control 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. _Diagram: Six groups of concepts — chapters 1–6 follow them. Chapter 7 is the habits that tie it all together._ ### 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. _Diagram: Left — a pile of copies, and no idea which is the real one. Right — one file plus a full history: any version can come back._ #### Version Control (VCS) - **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` — one `report.doc` and 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. _Diagram: Every save is a full snapshot of all files. The highlighted ones changed since the last save._ #### Git (version control system, snapshots) - **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. _Diagram: A repository = the working files you see + a hidden .git folder with every snapshot._ #### Repository (repo) - **What it is:** A project folder that Git watches: files + the whole history. - **How it works:** History lives in the hidden `.git` folder; the working files are what you see right now. - **Example:** `git init` turns a folder into a repo; `git clone` copies someone's repo whole, history included. - **Catch:** Delete `.git` and only the files remain — the whole history is gone. - **Related:** Made of **Commits**; comes as **local** (yours) and **remote** (on a server). > **The framing question:** "If I made a change and regretted it tomorrow, or two of us edited the same file today — could I recover cleanly? Version control is the system that makes the answer always yes." > 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. ## 2. The commit 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. _Diagram: Four commits: each has an ID and a message, and each points back to the one before. That chain is the history._ #### Commit (snapshot) - **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 commit `e81f53`. - **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. _Diagram: Three files changed, but only the two about login went into the box (staging area). The commit seals exactly those; notes.txt waits its turn._ #### Staging Area (the index) - **What it is:** An in-between "box" between your edits and a commit. - **How it works:** `git add` puts changes in the box, `git commit` seals it into a snapshot. - **Example:** Edited `login.js`, `login.css`, and `notes.txt` — staged only the first two, committed "add login". - **Catch:** Forget `git add` and 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. _Diagram: Left — a log that tells you nothing. Right — a log that reads like the story of the project._ #### Commit Message (the note on a commit) - **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. _Diagram: HEAD points to the main branch, and main points to the latest commit. The next commit lands after it, and HEAD moves forward._ #### HEAD (you-are-here pointer) - **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. > **The commit question:** "Does this commit capture one coherent change, with a message that would tell a stranger — or future me — what it did and why?" > 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. ## 3. Branches 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. _Diagram: The feature/login branch leaves main. Its commits f1–f3 live separately, and main doesn't see them._ #### Branch (line of work) - **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. _Diagram: main runs in a straight line. The feature/search and fix/date branches leave it and come back with a merge (M) only when ready._ #### main (primary branch, formerly master) - **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/search` and `fix/date` branches 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. _Diagram: The same folder: on main it has two files; after git switch feature/login — a changed app.js and a new login.js._ #### Switch / Checkout (changing branches) - **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.js` appears; `git switch main` — it's hidden, but safe. - **Catch:** Uncommitted edits can block a switch — commit them first. - **Related:** Moves **HEAD** between **Branches**. > **The branch question:** "Am I doing this work on its own branch, keeping main clean — so an unfinished or broken idea never touches the trusted version?" > 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. ## 4. Merging and conflicts 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. _Diagram: The feature branch (f1, f2) comes back into main. The merge commit M joins both lines — it has two parents._ #### Merge (joining branches) - **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. _Diagram: On main line 3 became “Hello, team!”, on feature — “Hi, world!”. Git can't know which is right, so it stops._ #### Merge Conflict (conflict) - **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. _Diagram: Left — the file with conflict markers: both versions sit between them. Right — what the human chose. Then git add and git commit._ #### Conflict Resolution (resolving) - **What it is:** Manually choosing the final version of a disputed spot. - **How it works:** Edit the file, remove the `<<<<<<<` / `=======` / `>>>>>>>` markers, then `git add` and `git 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**. > **The merge question:** "When these branches reunite, did they touch the same lines — and if Git asks me to resolve a conflict, do I understand both versions well enough to choose correctly?" > 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. ## 5. Remotes and the team 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. _Diagram: Everyone on the team has a full copy of the repo. The shared origin copy on GitHub or GitLab keeps everyone in sync._ #### Local / Remote (local and remote repo, origin) - **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. _Diagram: Clone — first copy. Push — send yours up. Pull — bring theirs down and merge. Fetch — download only, no merge._ #### Clone / Push / Pull / Fetch (the four sync commands) - **Clone:** `git clone ` — 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. _Diagram: Push the branch, open a PR, teammates review. Changes requested — fix and push again. Approved — merge into main._ #### Pull Request (PR, merge request) - **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**. > **The remote question:** "Did I pull the latest before starting, and is my finished work pushed and proposed — so the team can see it and nothing lives only on my laptop?" > 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. ## 6. Undo and history 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. _Diagram: git log: commits from newest to oldest, with author, date, and message. Dates broke? Look for the commit that changed date parsing._ #### Log (commit history, git log) - **What it is:** The list of every commit: ID, author, time, message. - **How it works:** `git log` shows 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. _Diagram: Top, revert: mistake C stays, and a new commit undoes it. Bottom, reset: HEAD jumps back to B, and C disappears from history._ #### Revert vs Reset (undo by commit / rewind history) - **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. _Diagram: Before: X and Y branch off B. After git rebase main: their copies X′ and Y′ sit after C — one straight line, no merge commit._ #### Rebase (replaying commits) - **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`, run `git 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 history question:** "If this goes wrong, can I read the log to find where — and am I undoing with the safe tool (revert for shared work), never rewriting history others already have?" > 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. ## 7. Using it well 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. _Diagram: One huge commit for a week versus four small ones: each about one thing, and any can be undone on its own._ #### Small Commits (small atomic commits) - **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 add` the 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. _Diagram: Top — short branches that come back quickly: conflicts stay tiny. Bottom — one long branch that drifted far: a big pile of conflicts at the end._ #### Feature Branch Workflow (a branch per feature) - **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**. _Diagram: The main links between the course's concepts: from an edit to main and back._ #### Your everyday Git habits - **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. #### Signs you use Git well - 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 Control** (VCS): One project + a full history; any version can come back. - **Git** (a timeline of snapshots): The most popular version control system; stores the project as snapshots. - **Repository** (repo): Project folder + hidden history in `.git`. ### The commit - **Commit** (snapshot): One saved snapshot with an ID and a link to its parent. - **Staging Area** (the index): The box before a commit: `git add` fills it, `git commit` seals it. - **Commit Message** (the note): A note to the future: what changed and why. - **HEAD** (you are here): Pointer to the current commit; moves forward with every commit. ### Branches - **Branch** (line of work): A parallel line of commits that doesn't touch anyone else's work. - **main** (primary branch (master)): The trusted, always-working version. - **Switch / Checkout** (changing branches): Move onto a branch: the folder's files change to its snapshot. ### Merging and conflicts - **Merge** (joining): Bring branches together; often via a commit with two parents. - **Merge Conflict** (conflict): Two branches edited the same line differently; Git asks you to decide. - **Conflict Resolution** (resolving): Choose the final version, remove the markers, commit. ### Remotes and the team - **Local / Remote** (origin): Your full copy and the shared copy on a server. - **Clone / Push / Pull / Fetch** (syncing): First copy · send yours · bring theirs and merge · download only. - **Pull Request** (PR, review): A proposal to merge a branch into main after review. ### Undo and history - **Log** (history): The list of commits: who, when, what, and why. - **Revert vs Reset** (undo): Revert — a new undo commit (for shared work). Reset — rewrite (only your own). - **Rebase** (replaying): Replay commits on top of another branch. Never on shared history. ### Good habits - **Small Commits** (atomic commits): One change — one commit with a clear message. - **Feature Branch Workflow** (a branch per feature): A short branch per task, merged often through a PR. End of express course · 7 chapters · 21 concepts Next comes practice: take any small project, run `git init`, and make a few commits as you change things — then create a branch, make an edit, and merge it back. Deliberately cause a conflict by editing the same line on two branches, and resolve it. The fear evaporates the moment you've done each thing once on something that doesn't matter. But hold one idea above the rest: Git is a save button that never forgets, and a way for many people to work without overwriting each other. Every intimidating word is just a name for one calm, recoverable step — and now you have them all.