Creating branch off of remote master

Question

I have problem understanding the logic behind the following command in Git:

git checkout -b hotfix_example_1 origin/master

If I type it then a local branch called hotfix is created that branches off of the master branch of my remote repository named origin. When I later push it to my remote repository the graph looks like this:

Say that a colleague makes changes and pushes them to the remote master branch and at some later point I decide to create another branch off of the remote master one called hotfix_example_2. When I push the new hotfix_example_2 branch to the remote repository I notice that the new branch I created is not branched off of the latest commit of remote master (the one that my colleague pushed earlier) but instead is branched off of the commit before that. If I do a

git pull origin master

on my local master branch and repeat the procedure, I can see that hotfix_example_2 is branched off of my colleague's commit. What I don't get is why do I have to do a git pull to get the graph I want even though I use origin/master in my checkout -b command. I am really sorry if it does not make much sense but english is not my native language.

Answer 1

Pretty much only pull and fetch retrieve new commits and update remote remote refs. Other operations only work on your local copy. When you create a branch, it is created off the specified ref, but that ref is looked up in the local repository only. You can see what this ref currently is for each remote branch under .git/refs/remotes/origin.

I would presume the goal behind this design is to allow completely disconnected operation. If checkout -b were to attempt to base the new branch on the remote ref in the remote repository, the remote repository would have to be contacted. By storing the ref locally, the branch can still be created even when completely disconnected.

Answer 2

What you explained makes sense, but all I can say is this is how Git is!

To update your 'remote' branch on server you need to talk to server atleast once. (Git pull does that).

Unless you did a git-pull your local repo did not know of the branch your friend had created. When you did a git-pull, it updated your local master(origin/master) also.

Hope this makes sense!

Answer 3

This is an old question but many of my teammates that are learning Git ask me this same question all the time, so it's very relevant 6 years later. Perhaps an alternative explanation will be helpful to those that happen upon this question:

This happens because when you reference origin/some-branch-name, you are not contacting the server. In Git there are 3 conceptual buckets of branches that you must keep track of in your head:

1. The branches on the remote server.
2. Your copy of the branches on the remote server (usually referred to as "origin").
3. Your local branches.

Every time you run the command git fetch you are updating your copy of the branches on the server (copying #1 to #2). Until you fetch, your local copy of "origin" will not be updated. Note that when you git pull, Git is actually doing 2 commands behind the scenes: git fetch and then git merge. This is why you can also update your copy of origin by pulling.

As a rule of thumb, I rarely use git pull, and instead I will git fetch before any command I run that references "origin" just to make sure I am dealing with the latest version of code on the remote server.

As a side note, you do not need to be connected to any network to work within Git, as most commands are performed out of buckets #2 and #3 which are physically on your machine. You only need to connect to the network/internet when you wish to git fetch or git push from/to the remote server (#1 bucket).