Git Graph in the Terminal and VS Code: Track Progress Without Micromanaging

The quickest way to see a git graph is in the terminal: git log --graph --oneline --all --decorate draws every branch as lines of text, one commit per line, with branch and tag names next to the commits they point at. In VS Code you can use the Source Control Graph that’s built into the Source Control view, or install the Git Graph extension for a bigger, clickable version. Both are covered in more detail at the end of this post.

Nobody enjoys being asked “how’s it going?” — and as the one leading a project at work, I still need to know how it’s going. My compromise is the git graph: I look at it before I ask anyone anything, and most of the time it already has the answer. It shows commit activity, branching and merging at a glance, and nobody has to sit in a meeting for it.

What the graph actually tells you

#

If you haven’t looked at one closely: every node is a commit, every divergent path is a branch, and the whole thing reads as a timeline of the project. That layout carries a surprising amount of information:

• A glance shows how many branches are active and how often commits are landing.
• A branch that suddenly goes quiet, or one that hasn’t merged for weeks, usually means someone is stuck. That’s an early warning worth having.
• Merge frequency tells you how the team collaborates. Frequent merges mean work is actually being integrated; long-lived branches usually mean someone has drifted off into siloed work.

Fewer interruptions, better conversations

#

The obvious win is that I don’t have to interrupt anyone to know where things stand. The bigger win is what happens when a conversation is needed: it starts from the graph rather than from assumptions. “This branch hasn’t moved since Tuesday — anything blocking you?” is a much better opener than “any updates?”

It also helps to make the routine explicit. Mine is a quick glance most mornings and a proper look once a week. The team knows that’s the rhythm, so nobody gets surprised.

Don’t turn it into surveillance

#

This is the part I have to keep reminding myself of. Commit count is not value — one thoughtful commit can beat fifty noisy ones. Seeing every commit doesn’t entitle you to question every decision; trust the team and step in only when a pattern genuinely looks like trouble. And when you do bring the graph into a conversation, it’s a starting point for feedback, not evidence for a prosecution.

Viewing the graph in the terminal

#

Nothing to install, just Git:

git log --graph --oneline --all --decorate

What each flag does:

• --graph draws the branch and merge lines down the left-hand side.
• --oneline puts each commit on one line: its short hash and the first line of its message.
• --all shows every branch and tag, remote ones included, instead of only the branch you’re on.
• --decorate prints branch and tag names next to the commits they point at. Recent versions of Git already do this when the output goes to a terminal, but the flag keeps them when you pipe the output somewhere else.

Nobody wants to type that every morning, so make it an alias:

git config --global alias.graph "log --graph --oneline --all --decorate"
git graph

On a long-lived repo the full graph scrolls forever. A few ways to cut it down:

git graph --since="2 weeks ago"    # only the last two weeks
git graph -20                      # only the last 20 commits
git log --graph --oneline main..feature                # on feature, not yet in main
git log --graph --oneline --left-right main...feature  # both sides, marked < and >

The last two compare two branches, and they use plain git log rather than the alias because --all would pull every other branch back in. Two dots shows what feature has that main doesn’t. Three dots with --left-right shows what each side has that the other doesn’t, which is a quick way to see how far a long-lived branch has drifted.

Viewing the graph in VS Code

#

VS Code has a graph built in. Open the Source Control view (Ctrl+Shift+G) and the Source Control Graph is one of the sections in that panel; it has been there since version 1.93 (August 2024). By default it follows the current branch and its remote, and the branch picker in the graph’s title bar adds others. For a quick look, that’s all you need.

For every branch at once, install the Git Graph extension by mhutchie (search for “Git Graph” in the Extensions view). Open it from the Git Graph item in the status bar, the Git Graph icon at the top of the Source Control view, or the Command Palette with Git Graph: View Git Graph (git log). Click a commit to see the files it changed, or click one commit and Ctrl/Cmd-click another to compare the two. It hasn’t had a release since 2021, which is one more reason the built-in graph is worth knowing about.

If the Git Graph button doesn’t appear, the extension probably hasn’t found a repository. By default it only checks the folders you opened, not their subfolders, so open the repository’s own folder or raise git-graph.maxDepthOfRepoSearch in the settings.

Other tools

#

Most Git tools draw a graph somewhere. gitk --all is Git’s own history browser. GitHub, GitLab and Bitbucket each have a “network” or “graph” view on the repository page. And the desktop clients, SourceTree (free, from Atlassian), GitKraken, Tower and TortoiseGit on Windows, all have one too.

Whichever you pick, the goal is the same: understand the progress, don’t count the commits.