Git branching and switching back to master is ahead?

Question

I have code that is working pretty good and created a branch to make some significant changes on my work computer with git checkout -b messaging. I committed my partially completed work and pushed it to my remote repository with git push origin messaging. Now that I'm home, I did a git pull origin messaging and am on that branch, but I want to switch back to master, but git checkout master gives me the following message:

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.

and all of the files from my modification of the messaging branch are there. git status informs me that I am on branch master, but that my branch is ahead of origin/master by 1 commit. I've figured out I can get to my real master two ways:

git checkout origin/master
git checkout master~1

However I'm confused about why this is happening, and I want to make sure that my changes to master won't affect the messaging branch and vice-versa. What I want to do is make origin/master my local master as well and keep messaging in its separate branch. Did I do something wrong to make master point to the messaging commit on my home computer? At this point I want to have two completely isolated branches.

Thinking about it more, when I did git pull origin messaging I was on my master branch, did that actually merge the messaging branch into my local master? If so, what should I have done (create local messaging branch and pull into that?) and how can I point my local master back to the commit without the messaging changes?

Answer 1

Oh, git pull... I don't like git pull; all it does is confuse people. So what happened?

Everything up until you when home and ran git pull origin messaging was fine. If you run git branch -av you'll see that origin/master and origin/messaging point to the commits you want.

So, what did the pull do?

git pull is really just a wrapper for a git fetch followed by a git merge. git fetch is easy; it just collected information on any snapshots the remote (specified by origin) had that you didn't have locally. In this case, one commit and branch named origin/messaging. Then, the pull ran git merge origin/messaging which merged the origin/messaging branch into whatever branch you currently had checked out (master). So, you unintentionally pulled the changes from origin/messaging into master.

Let's fix things up. First, put master back where it should be:

git checkout master
git reset --hard origin/master

Now, checkout a local branch called messaging based on your remote branch:

git checkout -b --track messaging origin/messaging

You can now continue to work on the messaging branch.

In the future, I recommend avoiding git pull. I find its semantics are confusing. Instead, run git fetch and then update each branch as you're interested in working on them with a merge or a rebase.

Answer 2

I think you have answered your own question. From the manual for git pull:

Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

In other words, you pulled the remote 'messaging' branch into your local master branch.

This is a general danger of doing git pull without really understanding what it's doing. It is, in essence, a git fetch followed by a git merge, which is obviously not what you wanted in this case. What you probably want to do is git fetch followed by git checkout --track origin/messaging. This will create a local messaging branch which tracks the remote—this is probably the behavior you expect.

This blog entry by Mark Longair does a good job of explaining git pull and why you're often better off explicitly fetching and merging.