Git Show All Branches: Master Your Repository

You're in a repo you haven't touched for a few days, and the first thing you need isn't another diff. You need a clean mental map of what's alive, what's stale, and what's already been merged. That's where git show all branches stops being a casual command and becomes part of your daily Git hygiene.

A branch list tells you more than names. It tells you whether the team is still pushing on feature work, whether the current branch is the right place to continue, and whether the repository is getting cluttered with old refs that nobody owns anymore. For teams that care about review speed and code health, that visibility matters as much as the code itself, a point that lines up well with Nerdify's guide to better code.

Table of Contents

• Why Viewing All Branches Is a Core Git Skill
• The Three Main Commands for Listing Branches
• Visualizing Branch History and Relationships
• Advanced Filtering to Find Specific Branches
• A Practical Workflow for Keeping Branches in Sync
• Beyond Listing Branches

Why Viewing All Branches Is a Core Git Skill

A new repo can look deceptively calm until you ask the right question. The state of work lives in branches, not just in the checked-out one, and the fastest way to get oriented is to list the full set before you edit a file or open a pull request. In practice, git show all branches is less about memorizing syntax and more about establishing your bearings.

A complete branch view answers the questions that matter first. Which features are still in flight. Which branches are already stale. Which remote-tracking refs exist locally after a fetch. That's why branch visibility is a practical code hygiene tool, not a cosmetic convenience. GitHub's branch views separate branches into Yours, Active, Stale, and All, which mirrors the same operational need, a fast way to distinguish live work from dead weight.

Practical rule: if you don't know which branches exist, you don't really know the shape of the repository yet.

That matters most in shared repositories where people create and delete branches constantly. A clean branch inventory helps you avoid accidental work on an old line of development and reduces the chance that you merge into the wrong target. It also makes cleanup easier, because you can spot branches that nobody is touching anymore before they become clutter.

For teams that want repository habits to stay tight, branch awareness belongs alongside every other version-control discipline. When you keep your eyes on the full branch set, you catch drift early, you review work with more context, and you spend less time guessing which branch should live or die.

The Three Main Commands for Listing Branches

The simplest branch command is also the one people forget to read carefully. git branch lists local branches only, and it marks the current branch with an asterisk so you can see where your next commit will land. If you run it in a repo with a few feature branches, the output looks like this:

$ git branch
* main
  feature/auth-refactor
  bugfix/login-redirect

That asterisk is useful because the command is not just inventory, it's state. If you're trying to avoid committing on the wrong branch, this is the first check I run. A terminal may color it differently, but the * is the reliable signal.

Remote visibility uses a different command. git branch -r lists remote-tracking branches only, which means the branches your local clone knows about on the remote after a fetch. This is the command to use when you want to see what the shared repo currently exposes without mixing in your own local work.

$ git branch -r
origin/main
origin/feature/auth-refactor
origin/release/1.4

That split matters in real teams because local and remote state drift apart. A branch can exist remotely even if you've never checked it out, and a local branch can still exist after someone deletes its remote counterpart. Git's branch views are useful precisely because they separate those cases instead of pretending they're the same.

git branch -a or git branch --all combines both views. It lists all local branches and remote-tracking branches, which is the standard answer when someone asks how to show all branches in a repository. If you want the full picture, this is the default command family to reach for.

$ git branch -a
* main
  feature/auth-refactor
  bugfix/login-redirect
  remotes/origin/main
  remotes/origin/feature/auth-refactor
  remotes/origin/release/1.4

If the repository is busy, git branch -a is the fastest way to see everything you already know about. A guide to grow your project's search visibility may sound unrelated at first, but the same discipline applies, structured visibility beats guesswork. You want the broad view before you decide whether a branch needs review, cleanup, or investigation.

The command choice comes down to intent.

• Use git branch when you only care about local work and the active checkout.
• Use git branch -r when you want the remote-tracking set and nothing else.
• Use git branch -a when you need the full inventory in one pass.

For people who work in repositories with lots of collaborators, that last one is the practical default. A local list can hide deleted remotes. A remote-only list can hide your in-progress branches. The combined view keeps both sides in frame.

Visualizing Branch History and Relationships

A list of names is fine until you need the story behind them. Branch topology matters when you're trying to answer questions like where a feature diverged, whether two branches share a merge point, or whether a line of work has drifted into its own mini-history. A flat list can't tell you that, but a graph can.

git log --graph --oneline --decorate --all is the modern command I reach for when branch relationships matter more than branch names. The --graph flag draws the structure, --oneline keeps it compact, --decorate labels refs, and --all pulls in every branch instead of just the one you're on. That combination gives you a fast forensic view of the repository's shape.

A branch list tells you what exists. A graph tells you how it got there.

That difference is not cosmetic. If a branch looks strange in git branch -a, the graph usually shows why. You can spot divergence points, merged commits, and branches that have continued long after the rest of the team moved on. In practice, that's the payoff of branch awareness, not just enumeration but context.

Git also has the older git show-branch command, and its documentation says it shows the commit ancestry graph starting from named revisions or, by default, refs under refs/heads and refs/tags. Historically, that made it one of Git's built-in ways to inspect multiple branches at once. Today, the more common workflow is the graph-style log command above, because it's easier to read during day-to-day debugging and branch review.

If you're comparing a feature branch to main, the graph gives you the shape of the disagreement. If you're auditing a messy repo, it helps you separate branches that were actively developed from branches that were created, touched once, and then abandoned. That's a level of visibility a plain branch listing just can't provide.

For teams working across multiple release lines, command discipline starts paying off. Use the list when you need inventory. Use the graph when you need to understand the history behind the inventory. The two commands solve different problems, and mixing them up wastes time.

Advanced Filtering to Find Specific Branches

A long branch list can be noisy, especially in active repos where feature work, release lines, and stale refs all pile up together. The trick is not to look harder at the same wall of names. The trick is to ask a narrower question.

git branch -v adds the latest commit information for each branch, which is useful when you want a quick sense of what changed last. git branch -vv goes further and can expose upstream tracking details, which makes it much better for diagnosing branches that are out of sync or pointing at the wrong remote. If a branch looks suspicious, that extra context saves a round of guesswork.

git branch --merged and git branch --no-merged are the cleanup commands. The first shows branches whose commits have already been integrated into the current branch, and the second shows branches that still contain work not present in the current checkout. That split is exactly what you need before deleting anything local.

A few practical filters are worth keeping in your muscle memory:

• Find matching branch names: git branch --list "feature/*"
• Inspect tracking status: git branch -vv
• Review safe cleanup candidates: git branch --merged
• Find branches still carrying unique work: git branch --no-merged

If you need custom output, git branch --format=... gives you control over what gets printed. That's helpful when you want to feed branch names into another tool or narrow the output to just the fields you care about. For ad hoc searches, shell pipelines with grep, awk, or comm are still common, especially in repos where branch naming conventions are consistent.

The same mindset shows up in other query-heavy workflows. If you're comfortable shaping a database query to answer a specific question, you'll feel at home using branch filters the same way. The point is not to list everything. The point is to isolate the exact branch state that matches the task.

For a deeper parallel on structured filtering and retrieval, the same thinking applies in a different domain, and the article on database queries is a useful mental model. You're narrowing a search space until the answer becomes obvious. Git branch filters do the same thing.

A Practical Workflow for Keeping Branches in Sync

The branch list only stays trustworthy if your local repo is current. That's why a fetch-first workflow matters, especially in repositories where branches appear and disappear often. If your local clone is stale, even the best listing command can give you a misleading picture.

The first habit is simple: run git fetch --all before you inspect branch state. That refreshes your remote-tracking refs so git branch -a reflects what the remote looks like now, not last week. In a busy team repo, that one step prevents a lot of false assumptions.

git fetch --prune is the cleanup companion. It removes local references to remote branches that have been deleted upstream, which keeps your remote-tracking list from filling up with junk. If you work in a repo where branches come and go quickly, pruning is the difference between a clean signal and a cluttered one.

After fetching, git branch -vv gives you a useful working view. It can show which local branches are tracking upstream refs, and it can reveal branches that are effectively orphaned or marked as gone. That's where cleanup decisions become straightforward instead of risky.

Practical rule: fetch first, inspect second, clean last.

A sensible daily routine looks like this:

1. Refresh remote state: git fetch --all
2. Remove deleted remote refs: git fetch --prune
3. Inspect all known branches: git branch -a
4. Check tracking details: git branch -vv
5. Cull merged local branches: git branch --merged followed by deletion only after review

That flow is especially useful before release work, before a long review session, or after returning to a repository you haven't opened in a while. It gives you a current map before you act on it.

For teams that keep deployment work organized through Git, this kind of branch hygiene feeds directly into delivery discipline. The article on deployment pipeline practices fits well here, because clean branch state makes pipeline decisions easier to reason about. If the branch inventory is accurate, the rest of the workflow is calmer.

There's one more reason to keep this loop tight. Branches that stay around too long create confusion for reviewers, and confusion turns into wasted time during merges. Keeping refs synced and pruned means your local view tracks the actual lifecycle of the work, not just the residue of old development.

Beyond Listing Branches

The main lesson is simple. git branch -a gives you the full branch inventory, git branch -vv adds tracking context, and git log --graph --oneline --decorate --all shows how the repository got into its current shape. Those three commands cover most of the practical work I need when I'm orienting myself in a repo.

The habit that matters most is the fetch-prune loop. If you keep your local refs current, your branch list becomes reliable instead of noisy, and cleanup stops feeling like a guessing game. That's the difference between just reading Git output and managing the repository well.

If you're comparing platform workflows too, the GitHub vs GitLab comparison is a good companion read because branch visibility often feels different depending on the hosting layer. The command-line habits stay the same, though, and that's the part worth building into muscle memory.

For teams that care about moving faster without losing control, branch inspection should be part of the normal rhythm. Pair it with the broader thinking in reducing time to market, and you'll see why clean Git hygiene is really a delivery habit, not just a developer preference. Keep the repo understandable, and everything downstream gets easier.

---

Webtwizz helps teams turn ideas into live products without getting bogged down in manual setup, and that same bias toward clarity applies to Git workflows too. If you want a faster path from messy branch state to a shippable app, visit Webtwizz and see how quickly you can go from concept to launch.

Last updated: July 26, 2026