How Git Works — snapshots, branches and history
How Git works, shown on an interactive canvas: the working directory, staging area, local and remote repositories, and how commits build a shared history.
Git is a snapshot-based version control system: every commit is a complete picture of the repository, linked to its parent, and branches are just pointers that move along the history.
How Git Works — snapshots, branches and history
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- Read the three columns left to right: Edit, Commit, Share.
- The four lane clusters are a pipeline: working directory to staging to local to remote — each arrow moves the change one step closer to being shared.
- The "Two people changed the same lines?" decision is the only branch, and both exits converge on the shared history at the end.
Editing and staging
"Developer edits files in the working directory" is the uncommitted reality — files on disk, not yet part of history. "git add moves changes into the staging area" is the deliberate middle step: staging lets you build a commit from selected changes rather than everything you touched. The visual separates these into their own clusters because the two-step commit is what gives Git its precision.
Committing the snapshot
"git commit snapshots the staged changes" is where a change becomes permanent. "Git stores the commit with a pointer to its parent" makes the graph explicit — every commit (except the first) names the commit before it, which is what makes history append-only and auditable. "The branch pointer moves to the new commit" completes the act: a branch is just a pointer, so committing on a branch is moving that pointer. Nothing about the commit itself cares which branch it is on.
Sharing history
"git push sends the commits to the remote" crosses from the "Local repository" to the "Remote repository" cluster — the only place data leaves your machine. "Remote repository records the new history" is the shared copy, and "Two people changed the same lines?" models the merge: Git merges divergent histories automatically unless the same lines were edited, in which case "Merge conflict — developer resolves it manually" makes the human decision explicit before "History is shared and up to date" closes the flow.
Key relationships and takeaways
- A commit is a full snapshot linked to its parent, which is what makes the history an append-only graph.
- A branch is a pointer to a commit, not a container of changes — creating and switching branches is cheap for that reason.
- Staging is the deliberate middle step that lets you choose what a commit contains.
- Git is distributed: everyone holds the full history locally, and push/pull only exchange the missing pieces.
- Conflicts are the exception, not the rule — and when they happen, a human resolves them explicitly.
When to use this visual
- Teaching the snapshot model to a team that has only ever used Git as a sequence of commands.
- Explaining branches, merges and conflicts through the pointer model rather than memorised commands.
- Grounding a review of a team's commit and branching workflow in how history is actually structured.
How it works
Trace your team's real workflow
Annotate the boxes with the commands your team actually uses — feature branches, pull requests, rebase versus merge — so the diagram documents your practice, not a textbook's.
Add the branch model
Insert feature-branch and main-branch rows into the local repository cluster, and draw the merge arrows between them, ending in the shared history.
Draw the pull-request gate
Add a decision between the local push and the remote recording: a review and CI check that must pass before the branch is merged into main.
Add the recovery paths
Include the undo branches — revert a commit, amend a message, reset to an earlier state — each ending in an explicit outcome, since recovery is half of real Git use.
Frequently asked questions
What is Git and how is it different from other version control?
Git is a distributed version control system based on snapshots. Each commit stores a complete picture of the repository plus a pointer to its parent, rather than just a list of file changes. Because every developer has the full history locally, most operations work offline, and collaboration is a matter of exchanging commits with remotes.
What is a branch in Git?
A branch is a movable pointer to a commit. When you commit on a branch, the pointer advances to the new commit; the commit itself does not know or care which branch it is on. That is why creating a branch is instant and why switching between branches only changes which snapshot your working directory shows.
Why does Git have a staging area?
The staging area lets you build a commit deliberately. You can edit several files, stage only the ones that belong together, and commit that selection — leaving unrelated work uncommitted. The working directory, staging area and repository are three separate states, which is exactly the pipeline the visual draws.
How does Git resolve merge conflicts?
When two branches change different files, or different lines, Git merges them automatically. When they change the same lines, Git cannot guess which version is right, so it marks the conflict and asks a human to choose. The conflict is a decision, not a failure — which is why the visual routes it to an explicit resolution step before history is shared.
Edit this visual in QueryChart (FlowJam)
Open this exact Git canvas as your own chart, rename the lanes to your workflow, and trace your own history.