How to Git Show All Branches: A Practical Guide

A mobile team usually hits this problem during a normal workday, not during a Git tutorial. The iOS developer pushes feature/onboarding-flow, the PM wants to review it before standup, and the designer opens the repo and says, “I can't see the branch.” From there, the conversation gets messy fast. Did the push fail? Is the branch private? Is someone on the wrong repo?

Most of the time, nothing is broken. The team is just looking at different views of the same distributed system. Git doesn't keep one magical live branch list that every person sees at the same moment. Each clone has its own local knowledge, plus a cached view of the remote.

That's why git show all branches is less about memorizing one command and more about understanding what kind of branch list you see. In a mobile app project, that matters because feature work tends to move in parallel. One branch for onboarding, one for push notifications, one for subscription screens, one for release prep. If the team can't see the same branch reality, review, QA, and release planning all slow down.

Why Is My Branch Invisible to the Team

A common mobile product scenario looks like this. A developer pushes a branch for a redesigned signup flow. The PM wants to verify the copy changes, and the Android developer wants to compare API assumptions before picking up their part. One teammate sees the branch. Another doesn't.

That confusion makes more sense once you remember how Git is built. Git's core design revolves around lightweight branch pointers, and the canonical commands for inspecting them are git branch for local branches, git branch -r for remote-tracking branches, and git branch -a for a combined view, as summarized in this Git branch listing reference. Because branches are lightweight pointers, listing them is fast. But fast doesn't mean globally live.

What the team is actually seeing

When someone says “I can't see your branch,” they usually mean one of three things:

• Their local repo is outdated. They haven't refreshed what Git knows about the remote.
• They're checking only local branches. git branch won't show remote-tracking branches.
• They're in the wrong clone or remote. This happens more than teams like to admit, especially with staging repos, forks, or archived mobile codebases.

For non-developers, the easiest mental model is this: each person has a local project copy and a local memory of the shared repo. If that memory hasn't been refreshed, branch listings can look incomplete even when the branch exists on the server.

Branch visibility is a team alignment problem first, and a command problem second.

Why this matters outside engineering

In a mobile workflow, branch visibility affects more than code. PMs use branch names to track which feature is ready for test builds. Designers use them to confirm that the right UI changes landed. QA uses them to match a bug report to in-progress work.

If the branch list is stale, the whole team starts making bad assumptions. Someone tests the wrong code. Someone reviews an old branch. Someone thinks a feature was never pushed.

That's why the practical question isn't just “how do I list all branches?” It's “how do I make sure my branch view matches the team's current reality?”

The Three Basic Commands to List Branches

If you want to git show all branches, start with the three commands that answer three different questions. They look similar, but they don't mean the same thing.

git branch for local branches

Run this first:

git branch

Example output:

  develop
* feature/onboarding-flow
  release/ios-hotfix

The * marks your current branch. This command only shows branches that exist on your machine.

In a React Native app repo, this is useful when you want to confirm whether you already created a local branch for something like feature/push-permissions or whether you're still on develop.

If you only need the current branch name, modern Git also supports:

git branch --show-current

That's handy in scripts, terminal prompts, or when you're double-checking before a commit.

git branch -r for remote-tracking branches

Now look at what your local repo knows about the remote:

git branch -r

Example output:

  origin/develop
  origin/feature/onboarding-flow
  origin/feature/paywall-copy-update
  origin/main

These are remote-tracking branches. They aren't the server being queried live in that moment. They are your local repo's record of remote branches.

origin/feature/onboarding-flow means, “my local clone knows there is a remote branch with this name on the origin remote.”

That origin/ prefix matters. It tells you which remote the branch is associated with. If your team uses forks or multiple remotes, this helps avoid reviewing the wrong branch.

For a broader Git refresher in a product team setting, this guide on using Git for version control is useful background reading.

git branch -a for everything your repo knows

To combine local and remote-tracking views:

git branch -a

Example output:

  develop
* feature/onboarding-flow
  main
  remotes/origin/develop
  remotes/origin/feature/onboarding-flow
  remotes/origin/main

This is the command typically intended when someone says they want to show all branches.

But “all” has an important limitation. It means all branches your local repository currently knows about. Not all branches that exist on the server right this second.

A quick walkthrough can help if someone on your team is more visual:

When each command is actually useful

Here's the practical version for a mobile team:

• Use git branch when you want to know what work you already have locally.
• Use git branch -r when you're checking what remote branches your clone has tracked.
• Use git branch -a when you want the broadest branch list in one place.

Practical rule: If a teammate says a branch exists and you can't find it with git branch -a, don't assume they forgot to push. First assume your local branch data is stale.

How to Sync and Find Newly Pushed Branches

Most branch visibility problems come from one wrong assumption. People think git branch -a talks to the server directly. It doesn't.

A better way to think about it is this: branch listing commands report what your local Git database already knows. If someone created or deleted branches on the shared remote and you haven't refreshed your remote-tracking refs, your output will be stale. That's why guides that stop at git branch -a usually leave people stuck. As explained in this note on missing Git branches, remote-tracking refs only update after a fetch, so this is a synchronization problem, not just a display problem.

The command that usually fixes the issue

If your teammate says, “I pushed the branch,” do this:

git fetch --all
git branch -a

That first command refreshes your remote-tracking refs. It updates your map of what the remotes currently expose. It does not switch your branch or merge code into your work.

Then git branch -a becomes useful again, because now it's working from fresher information.

git fetch --all is like downloading the latest branch map without moving your own workspace.

A simple troubleshooting sequence

When a branch is missing, don't jump straight into guesswork. Use a short sequence:

1. Check the remote

   git remote -v
   

   If the repo points at the wrong remote, no branch listing command will save you.

2. Refresh what your repo knows

   git fetch --all
   

3. List all known branches again

   git branch -a
   

4. If needed, inspect remote branch details

   git branch -r -v
   

That last command adds commit metadata alongside remote-tracking branch names, which helps when a branch exists but you're not sure whether it's the right one.

If your team is still getting comfortable with these mechanics, a practical companion resource is this guide to learn essential Git commands with Nerdify. It's useful for teammates who understand the workflow but still need command confidence.

Why mobile teams feel this problem more often

Mobile repos often have several parallel streams at once. A feature branch for a redesigned home screen. A release branch for App Store fixes. A hotfix branch for Android crashes. A prototype branch for an experiment the PM wants to validate fast.

When branch names are moving that quickly, stale remote-tracking refs create real coordination problems. QA may prep against the wrong branch. A developer may branch off old release work. A PM may think a feature isn't ready when the branch hasn't been fetched locally.

If your repository also feeds deployment or preview workflows, keeping that branch view fresh becomes part of normal team communication. For related repo update habits, this walkthrough on updating a GitHub repository fits well into the same routine.

Seeing More Than Just Branch Names

Once you can list branches reliably, the next question is usually not “what branches exist?” It's “which ones matter right now?”

That's where git branch -v and git branch -vv become more useful than a plain branch list. For large teams, a raw git branch -a can turn into noise, while commands like git branch -vv, --merged, and --no-merged help you focus on relevant work and cleanup decisions, as noted in this guide to listing Git branches effectively.

git branch -v for recent branch activity

Start here:

git branch -v

Example output:

  develop                  a1b2c3d Update auth copy for signup screen
* feature/onboarding-flow  d4e5f6g Add step indicator to onboarding
  main                     h7i8j9k Merge release fixes

This adds the latest commit reference and commit message for each local branch. In a mobile project, that helps answer a simple but important question: is this branch active, or is it old leftover work?

A PM looking at branch names may not know what feature/onboarding-flow-v2 means. The last commit message often makes it clearer.

git branch -vv for upstream tracking

Now add one more v:

git branch -vv

This shows more context, including the upstream branch your local branch tracks and the latest commit message for each local branch.

For non-engineers, upstream tracking is just the connection between your local branch and its remote counterpart. It helps answer questions like:

• Is my local branch tied to origin/feature/onboarding-flow?
• Am I looking at a branch that someone pushed, or only something local?
• Does this branch still belong in active work?

A branch name tells you what exists. Upstream tracking tells you how your local work relates to the team's shared repo.

Git Branch Flag Comparison

Useful filters when the branch list gets crowded

Two especially helpful cleanup commands are:

• git branch --merged
• git branch --no-merged

In a mobile app repo, --merged helps you find local branches that are already integrated and probably safe to remove. --no-merged highlights branches that still represent unfinished or unmerged work.

That's often more actionable than “show me everything.”

Visualizing the Project's Branch History as a Graph

A flat branch list tells you what names exist. It doesn't tell you the story of the project.

When a mobile team is preparing a release, that story matters. Did the paywall branch split from develop before the analytics refactor? Was the onboarding work merged already, or is it still diverged? Did a hotfix come off main and get backported cleanly?

The command that shows branch relationships

Use this:

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

A widely used practice for seeing every branch in context is exactly this command, and the key part is --all, which tells Git to show commits reachable from any branch reference, not just the current one, as discussed in this Git community thread.

The output is text-based, but it gives you a visual graph of commit ancestry. You can see where a branch split, where it merged, and how multiple lines of work relate.

Why the graph helps non-developers too

This command looks developer-heavy, but it solves product questions surprisingly well.

If a PM asks, “Did the onboarding copy branch make it into the release branch yet?”, a plain list of names won't answer that. The graph often will. It shows whether the commits are connected through merge history.

For a designer reviewing multiple UI experiments, the graph can also reveal whether two branches are siblings from the same base or whether one already includes the other's work.

The branch graph is less about branch names and more about project history. It shows how work moved, not just where labels exist.

A mobile app example

Suppose your team has these branches in play:

• main
• develop
• feature/onboarding-flow
• feature/paywall-copy-update
• release/ios-submission

A flat git branch -a output confirms those names exist. The graph tells you more useful things:

• whether release/ios-submission already contains onboarding changes
• whether the paywall copy work diverged before a major navigation refactor
• whether develop merged a hotfix that main has but your feature branch doesn't

That context is what helps teams avoid broken previews, duplicated bug fixes, and review confusion.

When to use this instead of branch listing

Use the graph when you need relationships, not inventory. It's especially good before:

• Release review, when you need to see what made it in
• Merge cleanup, when you're deciding if a branch still matters
• Code review handoff, when someone joins work midstream and needs history fast

Branch names answer “what exists.” The graph answers “how did we get here?”

Putting It All Together in Your Daily Workflow

The best branch habits are small and repeatable. Teams don't need a complicated Git ritual. They need a few dependable checks that reduce confusion before it spreads into QA, design review, or release work.

A strong default workflow is to fetch first, then inspect. A practical sequence is git fetch --all to refresh remote-tracking refs, then git branch -a to list all branches, and git branch -vv when you need upstream and latest-commit detail for local branches, as outlined in this remote branch workflow guide.

Three routines that work in a mobile team

Daily standup prep

Before standup, run:

git fetch --all
git branch -vv

This gives you a current view of what your local branches track and what changed most recently. It's a good habit for developers, and it also helps PMs or leads ask smarter questions about what's ready for test builds.

Code review branch lookup

If someone says, “please review my onboarding branch,” don't scroll through a noisy branch list manually. Search for it:

git branch -a | grep onboarding

That's often enough to find the exact branch name someone pushed.

Pre-release cleanup

Before cutting a mobile release, inspect branches that are already merged into your main line:

git branch --merged main

That helps identify old local branches that no longer need attention. It keeps the repository easier to scan during the next sprint.

Branch visibility is part of delivery hygiene

This isn't just terminal neatness. Branch visibility affects release confidence. Teams that can quickly tell which branch is current, which is stale, and which is tied to remote work spend less time guessing.

If your team is also revisiting broader branching habits, this article on optimizing development workflows is a useful companion read. And if you want a practical baseline for team process, these version control best practices are worth keeping close.

For product teams building mobile prototypes or feature branches quickly, tools like RapidNative can also fit into that workflow because they generate shareable React Native app code that teams can export into their own repos and manage through normal Git branching practices.

If your team is building mobile features fast and wants tighter alignment between product, design, and engineering, RapidNative is worth a look. It helps teams turn ideas, sketches, and PRDs into working React Native apps they can preview, iterate on, and hand off into a real repo where branch visibility and review workflows stay clean.