Git: Cannot see new remote branch

Question

A colleague pushed a new remote branch to origin/dev/homepage and I cannot see it when I run:

$ git branch -r

I still see preexisting remote branches.

I assume this is because my local remote refs are not up-to-date hence when I ran a git pull nothing happened since git pull only pulls on the current working branch correct? Unlike git push which pushes all branches that have changes to the corresponding remote branch?

Ablate

A related problem - Can't see remote branch – Parra

managed to forget git pull, thanks – Kooky

In my case git fetch <name-of-remote> did the trick. Without the name of the remote, it did NOT work. – Moniquemonism

Answer 1

First, double check that the branch has been actually pushed remotely, by using the command git ls-remote origin. If the new branch appears in the output, try and give the command git fetch: it should download the branch references from the remote repository.

If your remote branch still does not appear, double check (in the ls-remote output) what is the branch name on the remote and, specifically, if it begins with refs/heads/. This is because, by default, the value of remote.<name>.fetch is:

+refs/heads/*:refs/remotes/origin/*

so that only the remote references whose name starts with refs/heads/ will be mapped locally as remote-tracking references under refs/remotes/origin/ (i.e., they will become remote-tracking branches)

Apartheid

I was able to see the new remote branch after doing a git fetch origin, but not sure what the difference is if I just did a git fetch? I read about git remote update, but wasn't clear what that would have done. Would I need to run git fetch for any new remote branches from here on out? – Ablate

@Ablate If you use git fetch, git will download the references from the default remote repository that has been specified in .git/config: usually it will be called origin, so both commands are equivalent, but your specific configuration might be different for some reason. No, you don't need to give git fetch for every branch, as (by default) it fetches all branches. – Apartheid

My git is the default no changes to my config. Sorry, I meant if a new remote branch is added by someone that I need to work in, I would need to run git fetch origin again before i can track it? I worry about what git fetch will do to my other remotely tracked branches like develop and master when I'm still doing work in them. Guess I should pull on those before I fetch? – Ablate

@Ablate git pull is equivalent to git fetch + git merge (or git rebase if you have changed defaults), so you can keep using git pull as usual, and the new remote branches will pop up by themselves. – Apartheid

I originally ran git pull but i never saw that new remote branch which really confused me. Only until i ran git fetch origin. I appreciate the time in answering my questions. – Ablate

@hybrid I have the same issue. git ls-remote gerritrepo:project shows the new remote branch but git branch -a does not...I have to make another clone and only then the new branch will appear – Nonresistant

Thanks for the info! I didn't know about the ls-remote option! +1! – Holbrooke

@MarcoLeogrande +1 – Dementia

Thanks for your answer! I had this problem and somehow in my .git/config I had changed the * values for develop, so only develop branches where shown, and the rest were hidden. – Beestings

I also had to explicitly use git fetch origin to see the branch with git branch -a, not sure why though – Cinquefoil

git fetch worked like charm!! – Wife

My issue was that my .git/conf contained +refs/heads/master:refs/remotes/origin/master. I Replaced master with * as suggested here and now I can fetch new branches. In my case I think I had done a shallow copy during the initial git clone a long time ago and forgot about it. – Ave

problem disappeared after closing and opening the git command line window, which is in my case was "MINGW64". – Ambush

Why not git branch -r to confirm remote branch name exists followed git checkout -b <local branch name to use> origin/<remote branch name> to check it out against a local branch name? – Follicle

Answer 2

Check whether .git/config contains

[remote "origin"]
    url = …
    fetch = +refs/heads/master:refs/remotes/origin/master

If so, change it to say

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

Then you should be able to use it:

$ git fetch
remote: Counting objects: …
remote: Compressing objects: ..
Unpacking objects: …
remote: …
From …
 * [new branch]            branchname -> origin/branchname
$ git checkout branchname
Branch branchname set up to track remote branch branchname from origin.
Switched to a new branch 'branchname'

Antonetta

This happened to me after an initial shallow clone. – Pershing

Perfect!!! Thanks a lot! That happened to me when installing a custom Homebrew tap with the command brew tap user/repo: the local copy of the repo cloned by brew had the settings you mentioned and it was not possible to see and use the other branches I had in my repo. Thanks again! :) +1! – Holbrooke

The following command can be used instead of manual editing the .git/config file. git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*" and then git fetch origin to get all branches on origin. – Psychiatrist

this is a nice one! – Ci

I was facing this issue and the first answer didn't help me, but yours did. The reason, I think might be, that I have cloned only a single branch from the remote. – Transportation

happened to me when I cloned my repo as bare using TortiseGit – Windywindzer

or if it missing all together :P – Nathanialnathaniel

My older git repositories have this corrupted state, newer ones do not. The only differences I can see are: created in older versions of git (is git so awful that it isn't forwards compatible?), and ... the newer ones have been accessed by the GitHubDesktop app (is Github.com corrupting them?) – Charqui

omg i spent an hour troubleshooting, this worked for me finally, thank you! – Aerophone

Answer 3

The simplest answer is:

git fetch origin <branch_name>

Servais

This was literally the ONLY thing that worked for me. – Cherian

It doesn't work for me. I get this error: fatal: Couldn't find remote ref <branch_name> – Lanalanae

yes it did work for me as well, after this git checkout worked fine !! – Pathy

And this is an actual answer..... :) – Farkas

A thousand upvotes to this. – Cornwell

Even after this I cannot checkout the branch :( – Hostess

Answer 4

Let's say we are searching for release/1.0.5

When git fetch --all is not working and that you cannot see the remote branch and git branch -r not show this specific branch.

1. Print all refs from remote (branches, tags, ...):

git ls-remote origin Should show you remote branch you are searching for.

e51c80fc0e03abeb2379327d85ceca3ca7bc3ee5        refs/heads/fix/PROJECT-352
179b545ac9dab49f85cecb5aca0d85cec8fb152d        refs/heads/fix/PROJECT-5
e850a29846ee1ecc9561f7717205c5f2d78a992b        refs/heads/master
ab4539faa42777bf98fb8785cec654f46f858d2a        refs/heads/release/1.0.5
dee135fb65685cec287c99b9d195d92441a60c2d        refs/heads/release/1.0.4
36e385cec9b639560d1d8b093034ed16a402c855        refs/heads/release/1.0
d80c1a52012985cec2f191a660341d8b7dd91deb        refs/tags/v1.0

The new branch release/1.0.5 appears in the output.

2. Force fetching a remote branch:

git fetch origin <name_branch>:<name_branch>

$ git fetch origin release/1.0.5:release/1.0.5

remote: Enumerating objects: 385, done.
remote: Counting objects: 100% (313/313), done.
remote: Compressing objects: 100% (160/160), done.

Receiving objects: 100% (231/231), 21.02 KiB | 1.05 MiB/s, done.
Resolving deltas: 100% (98/98), completed with 42 local objects.
From http://git.repo:8080/projects/projectX
 * [new branch]        release/1.0.5 -> release/1.0.5

Now you have also the refs locally, you can checkout (or whatever) this branch.

Job done!

Dianthus

#2 worked for me, but I had to do it everytime I needed to fetch a remote branch. Updating the git config was the definitive fix for me. – Breastplate

Faced the same issue on the old repository. Deleting and downloading the repository again helped. – Enameling

Why not git branch -r to confirm remote branch name exists followed git checkout -b <local branch name to use> origin/<remote branch name> to check it out against a local branch name? – Follicle

Answer 5

Doing a git remote update will also update the list of branches available from the remote repository.

If you are using TortoiseGit, as of version 1.8.3.0, you can do "Git -> Sync" and there will be a "Remote Update" button in the lower left of the window that appears. Click that. Then you should be able to do "Git -> Switch/Checkout" and have the new remote branch appear in the dropdown of branches you can select.

Bahrain

git remote update is an old way to do this, the newer preferred command is git fetch. – Suffragist

In my version of TortoiseGit (2.8.0.0) the button in the lower left has multiple options under the arrow, and it remembers what you selected previously. This means the button might not say "Remote Update". If you haven't used it before it will say "Pull". So click on the arrow and you will see "Remote Update" in the list of options. – Markettamarkey

Answer 6

It sounds trivial, but my issue was that I wasn't in the right project. Make sure you are in the project you expect to be in; otherwise, you won't be able to pull down the correct branches.

Shaftesbury

Answer 7

I used brute force and removed the remote and then added it

git remote rm <remote>
git remote add <url or ssh>

Shenitashenk

Answer 8

What ended up finally working for me was to add the remote repository name to the git fetch command, like this:

git fetch core

Now you can see all of them like this:

git branch --all

Pectoral

Answer 9

You can checkout remote branch /n git fetch && git checkout remotebranch

Slowmoving