How Git Works, Visually

The mental model behind commits, branches, and merges

Pranjal Rawat

The problem, and the fix

Every result you trust rests on one question: exactly which version of the code and data produced it?

Git is the machine that gives that question an answer.

Life without version control

What version control gives you

For a data scientist, these three add up to one word: reproducibility.

A commit is a snapshot

The unit of git. One commit records three things.

Commits form a chain

Each commit points back to the one before it. That is the whole history.

The hash is a fingerprint

Each commit’s ID is computed from its contents. Change the past and every ID downstream changes with it.

That is how git guarantees the history has not been quietly tampered with.

How to read the diagrams that follow

Many of the diagrams from here on are a photograph of a real git repository. A command is run, and git’s actual state is read back and drawn.

A commit is a circle. An arrow runs to its parent. A colored box is a branch (just a pointer). HEAD marks where you stand. An amber ring is the commit the last command just made.

Use the arrow keys. Each step is one command, and the graph grows as you go.

What Git Is

Your First Commit

Seeing Your History

Ignoring Files with .gitignore

What a Commit Is

A change moves through three places

You edit, you choose what to record, then you record it.

Distributed: every copy holds it all

Clone a project and you copy the entire history to your machine, not just the latest files.

git is not GitHub

The Three Trees

Clone, Fetch, Push, Pull and the Three Mains

Branches, and how they rejoin

A branch is a separate line of work: a movable pointer that lets you build without disturbing the main line.

A branch is just a movable label

The fork: work in isolation

Merge: tie the lines together

Rebase: replay onto a straight line

A merge conflict is not an error

Your First Branch

A Branch Is a Pointer

Fast-Forward Versus a Merge Commit

Rebase and What It Rewrites

Anatomy of a Conflict

Working as a team

The mechanics of branching are settled. What teams argue about is the workflow: when to branch, how long a branch lives, when to merge.

Three workflows on one spectrum

The pull request

Where a branch is reviewed, tested, and let into main.

What a Pull Request Actually Is

Contributing With a Fork

GitHub’s Three Merge Buttons: Merge, Squash, or Rebase

The one tradeoff that runs backwards

Small, frequent merges beat one big one. This is the logic behind trunk-based development and feature flags.

Four ways teams work, on real repos

The workflow is not the mechanics. It is the set of rules a team agrees on: when to branch, how long a branch lives, when to merge. Four common shapes, each on a real repository.

Direct to Main

GitHub Flow: The Everyday Loop

Trunk-Based Development

GitFlow

Choosing a Collaboration Style

Parallel Work Without a Conflict

Two People Change the Same Line

Stacked Branches

When Your Branch Goes Stale

You can almost always undo

Git rarely loses committed work. A commit that is no longer on any branch still sits in the object store, and the reflog remembers every place HEAD has been. The next diagrams show the real safety net: reset, revert, restore, cherry-pick, and the reflog that recovers a “lost” commit.

Undo: Restore, Reset, Revert

The Reflog: Git’s Safety Net

Backporting a Fix With Cherry-Pick

Hotfixes and Reverting on Shared Main

Notebooks, Data, and Big Binaries

Worktrees for Parallel Agents

The Shared Checkout Hazard

Agent Commit and Review Hygiene

The words you will actually hear

THE CORE

commit a recorded snapshot, with a message and a parent

hash the fingerprint that identifies a commit

staging area the changes marked for the next commit

clone a full local copy, history and all

remote another copy you sync with

push / pull send commits up / bring commits down

BRANCHING

branch a movable pointer, a line of work

main the line treated as the source of truth

merge join two lines, recording a merge commit

rebase replay commits for a linear history

merge conflict same lines changed two ways, a human decides

pull request a proposal to merge, where review happens

The whole idea, in one line

A chain of snapshots,

each pointing at its parent.

Everything else, branches, merges, rebases, remotes, is bookkeeping on top of that.

Go deeper

Pro Git, 2nd edition - Scott Chacon and Ben Straub. The canonical book, free online.
What is Git? the three states and the distributed model
A successful Git branching model (git-flow) - Vincent Driessen
Trunk Based Development and GitHub flow

Built from the version-control notes in a software-engineering-basics collection.