How dotgit.dev works
Every lesson pairs a real Git command with a live simulation of a repository. You run the command, then inspect exactly what changed inside .git/ — the objects that were written, how the index moved, and where the branch refs point.
Nothing to install. The terminal, the object viewer, and the ref graph all run in your browser, so you can experiment safely and undo anything.
Lessons build on each other: start with what a version control system is, then work through init, add, commit, branching, merging, and beyond — until the whole object model feels obvious.
Accuracy, versions and formats
What is simulated. The browser terminal is a from-scratch model of Git's on-disk behaviour. It implements the object database, the index, refs, HEAD, and branch state so you can watch them change without touching a real repository. It is a teaching model, not a full Git build: exotic options, transport protocols, and many low-level flags are deliberately out of scope.
What is real. Every command shown in a lesson's command block is a genuine Git command. You can copy it, run it in a terminal on your own machine, and get the same structure and the same behaviour.
Object format. Examples use Git's default SHA-1 object format, which is why object IDs are 40 hexadecimal characters. Git also supports a SHA-256 object format (git init --object-format=sha256) where IDs are 64 characters. Content addressing, blobs, trees, and commits work identically; only the hash changes.
Reference storage. Examples show the default files reference backend, where a branch is a small text file under .git/refs/heads/. References can also be packed into .git/packed-refs, and Git supports an alternative reftable backend in which refs are not individual files at all.
Reproducing the output. File hashes are fully reproducible because a blob depends only on file content — so if you write exactly the same bytes, you get exactly the same hash. Commit and tree hashes embed author and committer timestamps, so the abbreviated IDs in a lesson are representative rather than identical on your machine.
Version-sensitive behaviour is checked against the official Git documentation, which we link next to detailed claims. Where a lesson depends on a specific setting or Git version, that is stated on the page.