Git Workflows You Can Actually See: Graphs and Diagrams

2026-03-27 · SPUNK13 · spunk.bet

Most confusion about branching comes from not being able to see the shape of the history. Three commands and one mental model fix that, and once you can read the graph, choosing a workflow becomes obvious rather than theological.

Draw the graph from the terminal

The canonical one-liner, worth aliasing:

git log --graph --oneline --decorate --all
git config --global alias.lg "log --graph --abbrev-commit --decorate \
  --format=format:'%C(bold blue)%h%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(auto)%d' --all"

Add --simplify-by-decoration when the history is too dense to read; it collapses everything that is not a branch or tag tip. Add --first-parent on a merge-heavy trunk to see only the merges into main, which is how you read release history without the noise of every feature commit.

Interactive viewers worth installing

• tig — terminal UI over git log. tig for history, tig blame <file>, tig status for staging hunks. Fast on large repos.
• gitk --all — ships with git, looks like 2005, and is still the quickest way to visually locate a commit that touched a specific file.
• lazygit — terminal UI with a graph pane, interactive rebase and cherry-pick that you can drive without memorising flags.
• Git Graph in VS Code — the least friction if you already live in the editor.

What each workflow looks like on the graph

Trunk-based is a single near-straight line. Branches exist for hours, not days, and merge back before they can diverge. On the graph you see main as a spine with tiny stubs. This is the workflow that produces the fewest conflicts, and it requires feature flags because unfinished work ships.

GitHub flow looks similar but the stubs are longer — a branch per pull request, merged on review. Squash merges keep main linear; merge commits keep the branch structure visible. Squashing makes git log readable and makes git bisect coarser, which is a real trade rather than a preference.

git-flow shows as two long parallel lines (main and develop) with release and hotfix branches crossing between them. The graph is genuinely hard to read, which is the honest argument against it. It earns its complexity only when you support multiple released versions simultaneously — shipping desktop software or firmware, not a web app that deploys ten times a day.

Reading a merge conflict from the graph

Before resolving anything, find the merge base: git merge-base main feature. That commit is where the two lines separated, and git log --oneline $(git merge-base main feature)..main shows exactly what landed on main while you were away. Ninety percent of "why is this conflict so bad" answers with "your branch is 300 commits behind", which the graph makes visible in one look.

Undo, visualised

git reflog is the history of where HEAD has been, including commits no branch points at any more. After a bad rebase or a hard reset, git reflog then git reset --hard HEAD@{3} restores the previous state. It keeps entries for 90 days by default, which means almost nothing you do locally is truly lost. Keeping a graph viewer open while you rebase turns the operation from guesswork into something you can watch happen.