Git Sourcetree Master 2 behind

Question

I am still working Git and Sourcetree out and am having trouble understanding how my Master branch is 2 behind my current branch which purports to be the master branch.

When I try to merge the master in to my current branch it says it is uptodate.

Can anyone explain to me how I got in to this situation and better yet, how I can get master up to date and work from it?

Thanks

EDIT: So I did as asked below, Checkout the master branch and pulled and that seems to have got it up to date except for the last few commits seem to have gone. Does anyone know why?

Answer 1

This means that master is 2 commits behind origin/master. You see that origin/master is on a merge commit that came after your master commit; that's one of the 2. The other one is on the "other side" of the merge ("Set up bundles...").

How you got here is, someone else pushed changes to master (in the form of merging in some other branch). You've fetched the changes from origin - at which point your local branch ref origin/master was updated - but you haven't yet merged (or pulled) them into master.

You can update master by checking out master and merging with origin/master (not master); or by doing a pull while on master (assuming tracking is set up in the expected way, which it probably is since you're getting the expected "2 behind" message). There are other ways, but those are the ones that make the most sense for this situation.

UPDATE

It seems when you did this, some commits appeared to vanish from your display. Most likely this means that your display is set up to show the history of what's currently checked out. (This would be the default for running git log; I'm not sure how SourceTree determines what to show, as I use the command line almost exclusively. It does appear from your screenshot that there's a drop-down control above the commit list, which might control what is being displayed.)

Now you want to be a little careful, because I see that you now have "uncommitted changes". Unlike commits (which are pretty hard to really lose), git is not doing anything to protect you from losing these uncommitted changes. So before doing any further checkouts, you should be sure you know what those changes are and whether they should be kept. If they should be, you should either commit or stash them before doing further checkouts. (At the command line, git would resist doing a checkout that would lose those changes; but again I can't speak for what SourceTree will do.)

Anyway, commits like "Fixing Log Out Bug" appear to have been created on some other branch; if you check that branch out, you should see those commits. Or if you change your display settings to show that branch (or --all) you should be able to see them.

You can see the history of what you've had checked out using the reflogs. Presumably the 3rd entry in the main reflog would be what you had checked out when creating the 1st screenshot in the question (unless you've done other checkouts (or similar operations) besides those I know about).