Introduction

If a teammate pushes a new branch and your local repository cannot see it, the problem is usually not the branch itself. In most cases, your local remote-tracking references are stale, your fetch configuration is restrictive, or you are looking at the wrong remote. The fix is usually quick once you understand how Git stores remote branch information locally.

Remote Branches Versus Remote-Tracking Branches

When people say "remote branch," they often mean two different things:

• the branch that exists on the server, such as origin/feature/login
• the local remote-tracking ref under refs/remotes/origin/...

Your local clone does not automatically know about every new remote branch forever. It learns about them when you fetch. That is why git branch -r can look outdated even though the branch already exists on the server.

Start with the normal refresh sequence:

git fetch origin --prune
git branch -r

--prune removes remote-tracking refs that no longer exist upstream, which keeps the listing accurate instead of letting old refs pile up.

Verify That the Branch Exists on the Remote

If the branch still does not appear after fetching, confirm that the remote server actually advertises it:

git ls-remote --heads origin

This command asks the remote directly for its branch heads. If your target branch is missing here, the branch was either not pushed, pushed to another remote, or deleted.

You should also verify that origin is the remote you think it is:

git remote -v

In repositories that use forks, origin might point to your personal fork while the new branch lives on upstream.

Create a Local Tracking Branch

Once the remote-tracking ref exists, create a local branch that tracks it:

git switch --track origin/feature/login

If you want a different local name, specify it explicitly:

git switch -c login-work --track origin/feature/login

Older Git versions use git checkout -b, but git switch makes the intent clearer.

Check for Restrictive Fetch Rules

Some repositories do not fetch every branch. This can happen in CI clones, shallow clones, or hand-edited .git/config files. Inspect the fetch spec:

git config --get-all remote.origin.fetch

The usual default looks like this:

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*

If you instead see something narrow such as +refs/heads/main:refs/remotes/origin/main, Git will only fetch that one branch. In that case, either broaden the fetch spec or fetch the missing branch explicitly:

git fetch origin refs/heads/feature/login:refs/remotes/origin/feature/login

That direct form is useful when you cannot or do not want to change the repository configuration.

Other Situations That Hide Branches

Case mismatches can also be the culprit. Git branch names are case-sensitive on the server, even if your local filesystem is not. Feature/Login and feature/login are different names.

Permissions can matter too. On some hosted platforms, you may not have access to see all references, especially in private or protected repositories.

A shallow clone can also surprise you. Shallow history usually does not prevent branch discovery by itself, but some tooling combines shallow checkout with restricted refspecs, which produces the same symptom: the branch exists remotely, but your clone never asks for it.

A Reliable Troubleshooting Flow

Use this sequence to isolate the problem quickly:

1git remote -v
2git fetch origin --prune
3git ls-remote --heads origin | grep 'feature/login'
4git config --get-all remote.origin.fetch
5git branch -r | grep 'feature/login'

If ls-remote sees the branch but branch -r does not, your local fetch behavior is the problem. If neither command sees it, look at the remote name, permissions, or whether the branch was actually pushed.

Common Pitfalls

One common mistake is assuming git pull will discover every new branch. git pull only fetches and merges the configured upstream for your current branch. It does not automatically create local branches for every new remote branch.

Another mistake is looking only at origin in a fork-based workflow. Teams often push feature branches to upstream, not to every developer fork.

Developers also forget about custom fetch specs set by tools or templates. If branch discovery behaves strangely in only one clone, inspect .git/config before blaming the remote.

Finally, do not create a new local branch with the same name and assume Git will connect it automatically. If the branch should track a remote branch, create it with --track or set the upstream afterward with git branch --set-upstream-to.

Summary

• New remote branches appear locally only after a fetch updates your remote-tracking refs.
• Use git ls-remote --heads origin to confirm the branch really exists on the server.
• Verify that you are checking the correct remote, especially in fork-based workflows.
• Inspect remote.origin.fetch if your clone is fetching only a subset of branches.
• Create a proper local tracking branch once the remote ref is visible.