How to switch (or checkout) to a existing remote branch in Git without facing detached HEAD

Question

At first when I clone the Git repository I am in the master branch. But I have already created a remote develop branch. I run git fetch origin develop. Then, I use git checkout develop and it switched to a new branch develop like this:

It creates local new develop branch. How to switch to my origin develop branch remote one. If I use git checkout origin/develop. It comes like this:

How can I switch to my remote develop branch?

Answer 1

When you check out develop, git doesn't complain the branch doesn't exist, so either

• you have a local branch named develop that you should delete (git branch -D develop) CAUTION may lose local progress there
• it really is checking out the remote branch

when you check out origin/develop, you're inspecting your copy of the remote's branch, which is why it has a detached head

Answer 2

You typically won't want to be working directly with the remote tracking branches. Instead, you would do a git fetch and then create a new local branch from the latest remote tracking branch, something like this:

git fetch origin                             # update remote tracking branch
git checkout -b your_develop origin/develop  # create new local develop branch

Answer 3

How can I switch to my remote develop branch?

You can't. You cannot work on a remote branch.

The way to start working at the end of a remote tracking branch is to branch locally from that point, usually using the same name and usually tracking the remote tracking branch.

Normally, if you have fetched origin/develop, this should work automatically to do just that:

git checkout develop

That is what your Git did in response, and it was correct. You should learn how branches work if you still don't see why.

As for your detached head: the only thing you can checkout without getting a detached head is a local branch name.

Answer 4

As in matt's answer, you literally can't do what you are asking to do. Git simply won't allow it.

Git's message here is, I think, confusing to beginners:

Switched to a new branch 'develop'.
Branch 'develop' set up to track remote branch 'develop' from 'origin'.

The phrase remote branch is misleading. What does remote branch actually mean? Different people will use this pair of words, exactly like this, to mean different things. So Git should probably not use it at all. A better message might be, e.g.:

Created new branch 'develop', with its upstream
set to 'origin/develop'.

Again, as in matt's answer, this is almost certainly what you want to use. But if you like, you can go ahead and use the detached-HEAD mode using either:

git checkout origin/develop

or:

git switch --detach origin/develop

This detached-HEAD mode makes sense if you merely want to look at that particular commit, and maybe even build a release from it, but not make any modifications.

If you want to do your own development, you need a (local) branch. The tricky thing here is that all branches are, literally, local to your own Git repository. Even the things I call remote-tracking names, such as origin/develop, are local to your Git repository. Each Git repository has its own names.

You can view any other Git's names—those it will show you, that is¹—and copy them to your own Git repository if you like, but your copies are yours, not theirs. Their names are theirs, and your names are yours.

When you clone a Git repository, you get all of its commits and none of its branch names. What you and the other Git repository share are the commits. It's the commits, not the names, that matter. The commits themselves have big ugly hash IDs, which are how Git actually looks them up in its big database of all-Git-objects. Any branch names just let you—and Git—find certain hash IDs. Other, non-branch names do the same thing, so non-branch names are just as good as branch names, with one particular exception: checking out a non-branch name results in a detached HEAD.

So, when you clone some Git repository from GitHub or Bitbucket or GitLab or whatever, your Git gets all their Git's commits. Then, your Git takes each of their branch names, such as develop, and renames them. Your Git sticks origin/² in front of each name. Last—as the final step of git clone—your Git effectively runs git checkout or git switch to create one new local branch, typically master or main,³ with its upstream set to the origin/ version of that name, which your Git copied from the other Git's un-prefixed version of that name.

(Parts of Git refer to this as tracking, which is another badly overloaded word. Your local branch is said to track its upstream. The upstream setting of a branch is just one of the various names in your repository, such as the origin/ version of the same name. Parts of Git refer to things like origin/develop as a remote-tracking branch name. I call these remote-tracking names, leaving out the badly overloaded word branch, but still with the somewhat overloaded tracking part.)

Later, you'll run git fetch—or have git pull run git fetch for you—and your Git call call up their Git to see if they have new commits in their repository. If they do, your Git will bring over their new commits. Your Git will see if their Git repository has changed the commit hash IDs stored in their branch names, and if so, will update your remote-tracking names: your origin/develop will update to remember where their develop is now.

In between git fetch-es that you run, their develop could be updated, and you won't know. So when you're wondering did they update their develop? that's when you would run git fetch. If they did update their develop, you will get any new commits from them, and your Git will update your origin/develop to track the update to their develop. That's why your origin/develop is a remote-tracking name.

In any case, this is why remote branch is such a poor phrase: does it mean develop on the other Git? Does it mean origin/develop in your own Git repository?

---

¹There's a set of facilities in Git, none of which seem quite satisfactory to me, for keeping various hidden names on Git servers. Since all of them have various flaws, few servers actually seem to make a lot of use of these—but I have no direct insight into how GitHub, Bitbucket, and GitLab run their services, so maybe they do use them and they work better than I think. :-)

²You can make Git use something other than origin here, but that's the default and hence what you are seeing. Technically these remote-tracking names are in a separate namespace, too, but we won't go into that here.

³The old standard, automatic first branch name was master; GitHub changed theirs to main and many have followed. There's nothing special about either name though, and your project might have a different first-branch-name. When you run git clone, you get to tell your Git which of their Git's branch names you want to copy, using the -b option. If you don't pick one, your Git asks their Git what they recommend, and copies that one. That's how your Git will follow GitHub's main recommendation, for instance.