A picture is a good place to start
Pick a course, or find the concept that's been on your mind.
Jump to concept search
Explore Git Hand-drawn. Made to click.
Make sense of the history behind every command.
Follow commits, branches and merges on a clear timeline, from your first commit to rescuing lost work.
Launch offer$99$79USD
One purchase. Lifetime course access. Price and checkout on Gumroad.
Explore Java Hand-drawn. Made to click.
See what is happening behind your code.
Collections, memory, generics and concurrency, drawn so you can see how the pieces work together.
$29USD
One purchase. Lifetime course access. Price and checkout on Gumroad.
Find your next skribble
156 skribbles to explore
Hand-named copies feel like history, but lose the thread between versions.
what you actually want: cheap save points, a note on each, instant travel or comparison between any two moments
a program on your machine keeping a repository inside your folder - not a website, no account needed
one install, one version check, one introduction - then the tool disappears into your folder
git shows diffs all day - so you assume it stores them. It doesn't.
twelve everyday commands - meet their names now, master each when its module comes
every dot on the history line is a full snapshot of every tracked file - watch the folder change, commit by commit
ask each commit for pasta.md: it answers with the whole file as it was - or says it was not there yet
five files edited, two different truths - the NEXT save needs a place to be assembled before it is sealed
one small record: a pointer to a snapshot, a note, and its parent - its id is a fingerprint of all of it
each commit points at its parent(s) - those links are the ancestry git keeps
the three places your work lives - and the seal that makes a moment permanent
every commit records its parent - that chain is the history you walk
every command acts FROM a branch - print that branch before the $ and you always know where you stand
git stores a snapshot as small objects, and a commit RECORDS it - the commit points at ONE tree, trees name blobs
an object's id is DERIVED by hashing its bytes - identical content gets the identical name, automatically
a branch is a ref under refs/heads holding ONE commit id - creating one writes a tiny pointer and copies nothing
the you-are-here pin - normally pinned THROUGH a branch name, which is why your branch follows you
blobs, trees, commits in the object database - plus the refs and HEAD pointing in
git init builds the archive - but the rail is born with the FIRST commit
init starts version control in a folder you already have; clone copies an existing project onto your machine - history and all
add chooses exactly what goes into the next commit; commit seals it with a message - the two-step is the whole point
the read-only report: which files differ across working directory, staging area, and last commit
-p stages chosen hunks of one file; -A stages everything repo-wide, deletions included; . reaches this folder down
-m writes the message inline; -a stages every TRACKED edit as it commits - and quietly skips anything untracked
plain: working directory vs staging area. --staged: staging area vs last commit. HEAD: working directory vs last commit.
log walks parent pointers backward from where you stand - --all adds every starting ref; --graph draws the shape
one commit, three lenses: the full patch, the file summary, and the X-ray of its bare record
patterns git leaves untracked by default - and why the list does nothing to files already committed
fix the last commit - the result is a NEW commit with a NEW id; keep it to work you haven't shared
edit, stage, commit - the loop you will run a thousand times, walked slowly once
status, diff, and log - the three commands that only look, never change
copy a clean version of one file back onto your desk - history never moves
--staged empties the tray (the staging area), desk untouched; --source pulls any bead's copy OVER your desk
HEAD and your branch walk back to an older commit - a mode dial decides the fate of staging and desk
a new commit whose change is the exact inverse of a bad one - history only ever grows
you cancelled it on your branch, so the branch looks clean - but a cancellation is a commit, and commits travel
git keeps a local log of your reference moves - a 'lost' commit is usually a lost pointer, and the reflog hands it back
git clean sweeps untracked files - and one question decides every rescue: did the bytes ever enter the object store?
four tools, one map: what each one touches, and the line none of them can cross
the messes everyone actually makes, and the exact way out of each - drill by drill
a new branch is just a second name on your commit - switch is what moves you, and it refuses to lose edits
-c creates the branch and moves in one motion; --detach visits a commit with no branch at all
one legacy word doing two different jobs - read it by its ARGUMENT
when the other branch continued your line, merge creates nothing - your branch name slides forward to their tip
one line splits, both sides work, git reunites them through the shared base - the whole story on one line
a merge never moves commits onto one line - each keeps its parents; git log just flattens the graph to fit
both branches changed the same lines to different results - git writes both versions into the file and waits for your ruling
read any diff window by its pane count - and by one color grammar
your editor's merge view - assemble the middle pane, then seal the ruling
the desk hands you more than same-line edits - every case ends the same way
the message, the deliberate record, and the exit - the three merge switches you will actually use
one scene, two honest endings - merge ties a knot keeping both lines; rebase re-files your commits with NEW ids
lift a slice of commits off one base and replant it on another - three arguments name the cut
one idea, two names: GitHub says Pull Request, GitLab says Merge Request - same thing, opposite vantage
branching and reuniting - and why the flat printout is a view, not the truth
a real merge weighs three things - and a conflict is the one question git cannot answer
your whole archive lives on one laptop - a remote names the second copy where work survives and teammates join
download their new records into YOUR archive - nothing you stand on moves
fetch downloads their commits and updates your remote-tracking refs - pull is fetch plus integrating
one command, two acts - the mail arrives AND gets filed into your branch
push asks the remote to move its branch - the everyday refusal means it holds commits you haven't seen
overwrite the remote branch ONLY if it still matches your last-known state - safer than --force, not safe in itself
a pull request is a hosted conversation around a pushed branch - every button on it is a graph move you know
behind/ahead compares two LOCAL pointers: your branch vs your bookmark - fresh only as your last fetch
another copy at an address, your bookmarks of it, and the mail rules between
push discipline, the honest rewrite, and the pull request that wraps it all
apply one commit's change onto your branch as a NEW commit - the original stays where it was
mark one good commit and one bad commit - git serves midpoints until ONE commit is left
sweep tracked edits + staged changes into a side drawer, clean desk - pop returns them after a clean apply
branches ride forward with every commit; a tag stays put on its commit - so v1.0 keeps meaning the same code
fix-typo drafts about to be shared - fold the noise into the clean run the story deserves
five power tools: copy a commit, hunt a bug, park a desk, seal a release, rewrite a run
git mergetool hands every tool the same three versions - yours, theirs, and the base both grew from
the CONFLICT line names the shape, the shape names your move - watch one shape ruled end to end
the <<<<<<< block is not damage - your side and theirs in plain text, and diff3 adds the base as referee
every button in every merge tool is one of four decisions - and git add is the resolved signal, not saving
during a rebase --ours is the branch you are rebasing ONTO - grabbing "mine!" keeps the other person's line
git checks text overlap, never meaning - verify the merge by diffing the result against each parent
after you revert a merge, re-merging brings nothing back while the branch has no NEW commits
the team rule: cut a temporary integration branch FROM the release branch, resolve the conflict THERE, fast-forward back
the stop, the markers, the three panes, the ruling - and the always-open door
directions, the release rule, the revert traps, and the verify discipline
the ovens' setting halved to 110, nobody remembers why - three queries answer it, each an IDE button's engine
-- <path> narrows the walk to one file's story; --follow keeps the story through renames
log ranges select COMMITS by reachability; diff ignores everything between and compares two endpoints
one commit id, author, and date stamped in the margin of each line - computed from history on demand
git diff <A> <B> lifts two snapshots and prints what differs - nothing in between is replayed
back-merge pulls main INTO your feature to stay current; forward-merge delivers the feature INTO main
five questions history answers - who, when, which lines, which commits, what changed
two lanes live forever (main, develop); feature, release and hotfix are opened for a job and closed - every route is fixed
one long-lived branch; work branches kept deliberately short - small merges collide less and hurt less
release/1.x lives beside main; a fix lands on main FIRST, then a copy is cherry-picked back to each supported release
a release line hardens while main moves on: bugfixes land on the release FIRST, hotfixes cut from what shipped
a branching strategy is a release-cadence decision wearing git clothes - pick the cheapest one your reality allows
three moves, arranged differently: cut a line, land it back, mark the release
open a second working folder, prove both share one repository, tear it down clean - type along
a second working folder on the SAME repository - no stash juggling, no second clone
every nickname this course speaks, next to the real thing - a page for coming back, not for memorizing
the honest index: ten tools we skipped on purpose, one line each on why they can wait
every chapter was a region of this picture - if you can redraw it from memory, you have the course
git help explains every command - one notation skill unlocks the ~150 verbs this course never teaches
Partial blueprint - some methods, some holes
Blueprints and instances - the core of Java
Initialize objects - same name as class, no return type
if/else - make decisions in code
Extend Exception - domain-specific errors
Private fields + public methods = controlled access
try / catch / finally - handle errors gracefully
🔒Automatic memory management in Java
🔒Type-safe containers - write once, use for any type
extends - child class inherits from parent
Contract - what a class must do, not how
🔒Stack vs Heap - where your data lives
🔒From .java to running bytecode
for, while, for-each - repeat with control
Reusable blocks of code with inputs and outputs
Arithmetic, comparison, logical, and ternary
One supertype, many implementations
Deep dive - trim, replace, split & more
🔒Why identical strings can share one object
Immutable text - the most-used Java type
Where every Java program begins
The building blocks of Java data
Autoboxing - primitives meet objects
🔒Double-ended queue - fast at both ends
🔒Your go-to List for most use cases
🔒Fixed-size, indexed, type-safe containers
Inside put & get - hashing, buckets, collisions
🔒Fast access by key - O(1) average
🔒Unique elements with average O(1) lookup
🔒for-each, Iterator, forEach - three ways to loop
Know the landscape before picking a collection
🔒Doubly-linked nodes - O(1) at both ends
Key-value pairs for fast lookups
A quick decision guide
🔒Heap-ordered queue - smallest out first
🔒FIFO processing - first in, first out
🔒Comparable vs Comparator - natural vs custom order
🔒Red-black tree - keys always in order
🔒Red-black tree - elements always in order, no duplicates
Arrays vs Collections - know the difference
🔒Predicate & Function - lambdas with a contract
Concise syntax for anonymous functions
🔒Represent an absent return value explicitly
🔒Recipes that collect() applies to a stream
🔒Transform collections step by step
🔒Thread-safe collections without full locking
🔒Coordinating shared state between threads
🔒Creating and running threads in Java
🔒Why 0.1 + 0.2 is not 0.3
🔒Why == lies for boxed values
🔒Why your HashSet loses the live object
Why your HashSet loses the object
🔒Why a return in finally hides bugs
🔒Why removing in a loop throws
