How Does It Work?

Visual Git does not invent a picture of your repository. It reads the real thing — the objects and references Git itself stores in the .git folder — and draws exactly what is there.

Reads your repository directly

Never modifies anything

Runs entirely on your machine

Everything lives in the .git folder

Every repository has a hidden .git folder, and almost everything Git knows is stored inside it. Your entire history, every version of every file, every branch and tag — all of it sits in there as ordinary files on disk.

Most tools hide this from you and show a tidy list of commits instead. Visual Git opens it up and shows you the actual contents, because once you can see the shape of it, commands like rebase and reset stop being mysterious.

your-project/.git

objects/   every version of everything
refs/
├── heads/  your branches
└── tags/   your tags
HEAD       where you are right now
index      the staging area

Git stores just a few kinds of thing

The object folder holds thousands of files, but they are only ever one of a handful of types. Each one gets its own colour on the canvas.

Blob

The contents of a file, with no name attached. Save the same file twice and Git stores it once.

Tree

A folder. It lists filenames and points at the blobs and trees inside it.

Commit

A snapshot. It points at one tree, at the commit or commits that came before it, and carries your message.

Branch

Just a name pointing at a commit. This is why creating a branch is instant — nothing is copied.

Tag

Another name pointing at a commit, but one that is meant to stay put.

HEAD

A pointer to the branch you have checked out, so Git knows where your next commit goes.

point at commits

↓

point at a tree

↓

point at files

↓

file contents

Following the connections

Every object is stored under a long hash rather than a filename, and each one refers to others by hash. Visual Git reads each object in turn, asks Git what type it is and what it contains, and follows those references outward.

A commit leads to its tree, that tree leads to its files and sub‑folders, and its parent link leads back through your history. Branches, tags and HEAD are read from the reference files and hooked onto the commits they name.

Follow all of that and you have the whole graph — which is exactly what appears on screen, arrows and all.

Including the parts you normally can't see

The interesting moments in Git are often the in‑between ones. When you stage a file, Git writes a blob straight away — before any commit exists. Visual Git picks these up and shows them floating there, unattached, waiting.

The same goes for objects left behind by a reset or an amended commit. They are still on disk, no longer reachable from any branch, and you can watch them sit there until Git eventually cleans them up.

Alongside the graph, panels show your working directory and staging area, so you can see a change move from one to the other as you type.

Working

data.txt

→

Staged

data.txt

→

Committed

watching

Keeping up as you work

Because everything Git does ends up as a change to a file on disk, Visual Git can simply watch the repository folder. Run a command in your terminal and the app notices immediately, re‑reads the repository and redraws.

There is no refresh button and no polling delay. Put your terminal beside the app, run git commit, and watch the new node appear and the branch pointer move across to it.

Worktrees too

If you use worktrees to keep several branches checked out at once, they share a single object store between them — one history, several working folders.

Visual Git understands this arrangement and shows each worktree along with the branch it has checked out, so you can see how they sit against the shared history.

main

feature-a

hotfix

↓

shared history

Your Code Stays Yours

Earlier versions of Visual Git uploaded a snapshot of your repository to the cloud so that a website could draw it. That is gone. Everything now happens inside the desktop app: your repository is read on your machine, drawn on your machine, and never sent anywhere. The only thing the app sends is an anonymous count of how often it is used, which contains no file names, no history and no code.