Your visual Git course
Git, one skribble at a time.
102 skribbles · 30 free · 12 modules
Git as a time machine you can watch: every command drawn on one timeline, from your first commit to rescuing lost work and merging with a team.
Explore the free skribblesUnlock every Git skribble and video: one purchase, yours to keep.
$99$79 USD
Where Your Work Lives

You Already Do Version Control
Hand-named copies feel like history, but lose the thread between versions.

Git: A Time Machine for a Folder
what you actually want: cheap save points, a note on each, instant travel or comparison between any two moments

What Git Is (and Is Not)
a program on your machine keeping a repository inside your folder - not a website, no account needed

Getting Git Onto Your Machine
one install, one version check, one introduction - then the tool disappears into your folder

Snapshots, not diffs
git shows diffs all day - so you assume it stores them. It doesn't.
The Verbs You Will Keep Using
twelve everyday commands - meet their names now, master each when its module comes
A Commit Holds Your Whole Folder
every dot on the history line is a full snapshot of every tracked file - watch the folder change, commit by commit
One File, Three Moments
ask each commit for pasta.md: it answers with the whole file as it was - or says it was not there yet

Git's Three Areas
five files edited, two different truths - the NEXT save needs a place to be assembled before it is sealed

What a Commit Really Is
one small record: a pointer to a snapshot, a note, and its parent - its id is a fingerprint of all of it

History Is a Graph
each commit points at its parent(s) - those links are the ancestry git keeps

Where Your Work Lives
the three places your work lives - and the seal that makes a moment permanent

Beads on a Thread
every commit records its parent - that chain is the history you walk
Inside .git: the Object Store
The Prompt Shows Where You Stand
every command acts FROM a branch - print that branch before the $ and you always know where you stand
Blobs, Trees, Commits
git stores a snapshot as small objects, and a commit RECORDS it - the commit points at ONE tree, trees name blobs
Content Addressing
an object's id is DERIVED by hashing its bytes - identical content gets the identical name, automatically

A Branch Is Just a Name
a branch is a ref under refs/heads holding ONE commit id - creating one writes a tiny pointer and copies nothing
HEAD: Where You Are Standing
the you-are-here pin - normally pinned THROUGH a branch name, which is why your branch follows you

Inside .git: the Object Store
blobs, trees, commits in the object database - plus the refs and HEAD pointing in
The Daily Loop

A Timeline Is Born
git init builds the archive - but the rail is born with the FIRST commit
git init & git clone - Two Ways to Get a Repository
init starts version control in a folder you already have; clone copies an existing project onto your machine - history and all

git add & git commit - Saving in Two Steps
add chooses exactly what goes into the next commit; commit seals it with a message - the two-step is the whole point
git status - What Differs, and Where
the read-only report: which files differ across working directory, staging area, and last commit
git add -p, -A, and . - Choosing What You Stage
-p stages chosen hunks of one file; -A stages everything repo-wide, deletions included; . reaches this folder down
git commit -m and -a - The Sealing Controls
-m writes the message inline; -a stages every TRACKED edit as it commits - and quietly skips anything untracked
git diff - Three Comparisons, One Command
plain: working directory vs staging area. --staged: staging area vs last commit. HEAD: working directory vs last commit.
git log - Walking History, Three Lenses
log walks parent pointers backward from where you stand - --all adds every starting ref; --graph draws the shape
git show - One Commit Under the Lamp
one commit, three lenses: the full patch, the file summary, and the X-ray of its bare record
.gitignore - Telling Git What to Leave Alone
patterns git leaves untracked by default - and why the list does nothing to files already committed
git commit --amend - Redo the Last Commit
fix the last commit - the result is a NEW commit with a NEW id; keep it to work you haven't shared

The Daily Loop
edit, stage, commit - the loop you will run a thousand times, walked slowly once

Reading Your Repository
status, diff, and log - the three commands that only look, never change
Undo Without Fear
git restore - Put a File Back
copy a clean version of one file back onto your desk - history never moves
restore --staged & --source
--staged empties the tray (the staging area), desk untouched; --source pulls any bead's copy OVER your desk
git reset - Walk the Branch Back
HEAD and your branch walk back to an older commit - a mode dial decides the fate of staging and desk
git revert - Undo by Adding
a new commit whose change is the exact inverse of a bad one - history only ever grows
The Revert Travels With the Merge
you cancelled it on your branch, so the branch looks clean - but a cancellation is a commit, and commits travel

git reflog - Where HEAD Has Been
git keeps a local log of your reference moves - a 'lost' commit is usually a lost pointer, and the reflog hands it back
What Git Can Never Bring Back
git clean sweeps untracked files - and one question decides every rescue: did the bytes ever enter the object store?

Undo Without Fear
four tools, one map: what each one touches, and the line none of them can cross

The Rescue Playbook
the messes everyone actually makes, and the exact way out of each - drill by drill
Timelines
git branch & git switch: Name First, Move Second
a new branch is just a second name on your commit - switch is what moves you, and it refuses to lose edits
git switch -c and --detach: Two Ways to Move
-c creates the branch and moves in one motion; --detach visits a commit with no branch at all
git checkout: The Old Master Key
one legacy word doing two different jobs - read it by its ARGUMENT
Fast-forward: The Merge With No Merge Commit
when the other branch continued your line, merge creates nothing - your branch name slides forward to their tip
The Three-Way Merge: One Commit, Two Parents
one line splits, both sides work, git reunites them through the shared base - the whole story on one line
git log Prints a List. History Is a Graph.
a merge never moves commits onto one line - each keeps its parents; git log just flattens the graph to fit

Merge Conflict: Git Asking a Question
both branches changed the same lines to different results - git writes both versions into the file and waits for your ruling
Two Panes Compare, Three Panes Rule
read any diff window by its pane count - and by one color grammar
The Ruling Desk: Both Moved One Line
your editor's merge view - assemble the middle pane, then seal the ruling
Rulings Beyond One Line
the desk hands you more than same-line edits - every case ends the same way
git merge Arguments: -m, --no-ff, --abort
the message, the deliberate record, and the exit - the three merge switches you will actually use
Rebase vs Merge: Two Endings for a Stale Desk
one scene, two honest endings - merge ties a knot keeping both lines; rebase re-files your commits with NEW ids
git rebase --onto: The Transplant
lift a slice of commits off one base and replant it on another - three arguments name the cut
Pull Request = Merge Request
one idea, two names: GitHub says Pull Request, GitLab says Merge Request - same thing, opposite vantage

Timelines
branching and reuniting - and why the flat printout is a view, not the truth

How Merging Works
a real merge weighs three things - and a conflict is the one question git cannot answer
Remote Repositories
git remote - Naming the Server Copy
your whole archive lives on one laptop - a remote names the second copy where work survives and teammates join
git fetch: The Mail Arrives, Held
download their new records into YOUR archive - nothing you stand on moves
git fetch vs git pull - Look First, Then File It In
fetch downloads their commits and updates your remote-tracking refs - pull is fetch plus integrating
git pull: Fetch, Then File It In
one command, two acts - the mail arrives AND gets filed into your branch
git push - The Refusal Is Protection
push asks the remote to move its branch - the everyday refusal means it holds commits you haven't seen
git push --force-with-lease - The Safer Force
overwrite the remote branch ONLY if it still matches your last-known state - safer than --force, not safe in itself
The Pull Request Loop - Branch, Push, Review, Merge
a pull request is a hosted conversation around a pushed branch - every button on it is a graph move you know
"Your Branch Is Behind" - Behind and Ahead, Decoded
behind/ahead compares two LOCAL pointers: your branch vs your bookmark - fresh only as your last fetch

Remote Repositories
another copy at an address, your bookmarks of it, and the mail rules between

The Collaboration Loop
push discipline, the honest rewrite, and the pull request that wraps it all
The Sharp Tools
git cherry-pick - Copy One Commit's Change
apply one commit's change onto your branch as a NEW commit - the original stays where it was
git bisect - Find the Breaking Commit by Halving
mark one good commit and one bad commit - git serves midpoints until ONE commit is left
git stash - Park Half-Done Work
sweep tracked edits + staged changes into a side drawer, clean desk - pop returns them after a clean apply
git tag - A Name That Does Not Advance
branches ride forward with every commit; a tag stays put on its commit - so v1.0 keeps meaning the same code
git rebase -i - Rewrite a Run of Commits
fix-typo drafts about to be shared - fold the noise into the clean run the story deserves

The Sharp Tools
five power tools: copy a commit, hunt a bug, park a desk, seal a release, rewrite a run
Reading a Merge Conflict
The Merge View: Three Panes, One Ruling
git mergetool hands every tool the same three versions - yours, theirs, and the base both grew from
Merge Conflicts Have Shapes
the CONFLICT line names the shape, the shape names your move - watch one shape ruled end to end
Reading Conflict Markers
the <<<<<<< block is not damage - your side and theirs in plain text, and diff3 adds the base as referee
Resolving: Four Moves, One Exit Door
every button in every merge tool is one of four decisions - and git add is the resolved signal, not saving
The Rebase Flip: ours Is Not Yours
during a rebase --ours is the branch you are rebasing ONTO - grabbing "mine!" keeps the other person's line
A Clean Merge Can Still Be Wrong
git checks text overlap, never meaning - verify the merge by diffing the result against each parent
Reverting a Merge: the Dead End
after you revert a merge, re-merging brings nothing back while the branch has no NEW commits
Never Resolve on the Release Line
the team rule: cut a temporary integration branch FROM the release branch, resolve the conflict THERE, fast-forward back

Reading a Merge Conflict
the stop, the markers, the three panes, the ruling - and the always-open door

Merging on a Team
directions, the release rule, the revert traps, and the verify discipline
Repository Archaeology
Your IDE's History Views Are Git Queries
the ovens' setting halved to 110, nobody remembers why - three queries answer it, each an IDE button's engine
git log Can Answer for One File - Even Across a Rename
-- <path> narrows the walk to one file's story; --follow keeps the story through renames
log A..B Asks the Graph. diff A B Compares Snapshots.
log ranges select COMMITS by reachability; diff ignores everything between and compares two endpoints
git blame: Who Last Touched Every Line
one commit id, author, and date stamped in the margin of each line - computed from history on demand
Compare Any Two Moments, Any Time
git diff <A> <B> lifts two snapshots and prints what differs - nothing in between is replayed
Back-Merge, Forward-Merge: Two Directions
back-merge pulls main INTO your feature to stay current; forward-merge delivers the feature INTO main

Repository Archaeology
five questions history answers - who, when, which lines, which commits, what changed
Choosing Your Strategy
Git Flow - Five Lanes, Fixed Jobs
two lanes live forever (main, develop); feature, release and hotfix are opened for a job and closed - every route is fixed
Trunk-Based - One Line, Tiny Branches
one long-lived branch; work branches kept deliberately short - small merges collide less and hurt less
Release Branches - Supporting Old Versions
release/1.x lives beside main; a fix lands on main FIRST, then a copy is cherry-picked back to each supported release
Stabilization Flow - Bugfix vs Hotfix
a release line hardens while main moves on: bugfixes land on the release FIRST, hotfixes cut from what shipped
Choosing a Branching Strategy
a branching strategy is a release-cadence decision wearing git clothes - pick the cheapest one your reality allows

Choosing Your Strategy
three moves, arranged differently: cut a line, land it back, mark the release
One Archive, Many Desks
Worktrees - The Practice Run
open a second working folder, prove both share one repository, tear it down clean - type along

One Archive, Many Desks
a second working folder on the SAME repository - no stash juggling, no second clone
Reference
The House Words
every nickname this course speaks, next to the real thing - a page for coming back, not for memorizing
What This Course Did NOT Cover
the honest index: ten tools we skipped on purpose, one line each on why they can wait
The Whole Course on One Line
every chapter was a region of this picture - if you can redraw it from memory, you have the course
Reading the Manual - the Decoder Ring
git help explains every command - one notation skill unlocks the ~150 verbs this course never teaches
Videos
Watch the ideas come together: 19 videos are free to watch, the rest unlock with the course.
