Git- how can I be sure that my local master is the same as the one on the server?

Question

I am working on some software that has been written in Python/ Django, and have just tried running a git pull origin master on my local machine, and was given the output:

Already up-to-date.

However, I am suspicious of this, because I know for a fact that some changes have been made to the version on the server since I was last in the office...

When I was last in, there were some errors on the version on the server, which had broken the site, these errors have been fixed when I was out of the office, and I now want to pull the working version from the server, to ensure that when working on a local copy, I am working on the latest version, so won't be pushing the errors that have been fixed back onto the server when I next push my changes to the server.

How can I ensure that my local master branch is definitely up-to-date with the master on the server? Is there a way to 'force' git to pull from the server and overwrite my local branch, even though it thinks that my local branch is already up to date?

Answer 1

First make sure that you actually have the latest changes:

git fetch
git log origin/master

Make sure that that contains the commits you expect. If it doesn't then it's likely that they weren't committed to master on the server like you think they are. Possibly they were put on another branch or something. You'd need to check the server repo. I suppose it's possible that git fetch silently failed, but I've never seen that.

Second, hard reset your local branch to the remote:

git reset --hard origin/master

That will skip any merge, fast forward, etc, and just point your local branch at the same commit as the origin and reset your workspace.

Answer 2

First, start by forgetting everything you know about branch names. :-) The problem here is that these names are almost a sort of hint. Anyone can change them, any way they like, any time. A branch name just helps you (and Git) get started in terms of finding commits. The names don't matter; it's the commits that matter.

(If people are careful and disciplined about the way they use the names, the hints will never mislead you. Are you, and your team, and any people not on your team who you're also relying upon, all very careful and disciplined? If the answer is "no" even one day of the year, you'll want to pay attention to commits. Starting from the hints is fine, it's like believing that the sugar bowl for the coffee really does contain sugar. But if you have an office prankster and the coffee goes weird, maybe the sugar bowl is now full of salt.)

Now that you know what not to trust: how to view commits

You would think git log would be the way to view commits ... and it is, but by default it doesn't show you everything. This is on purpose: "everything" is usually way too much. In my opinion, though, what it shows you by default often isn't enough. This may be one reason Git GUIs are so popular.

There is no perfect viewer. See Pretty git branch graphs and Visualizing branch topology in git for many possibilities. Gitk by default shows you more than git log. Both, however, by default start from HEAD. What I personally do most often is to get help from a dog: git log --all --decorate --oneline --graph. (I actually have this as an alias, git lola, but "a dog" is even more memorable! Instead of --all, you might want --branches or --branches --remotes, but --all is the only way to get A DOG out of it.) You get the same thing, but in graphics, with gitk --all.

Anyway, the point is that this kind of view, that (a) includes the graph and (b) shows you all starting-points (including all branch and remote-tracking branch names), gives you a great deal more information. You will be able to see commits you have that they don't, and commits they have that you don't.

If you want to discard what you have

Sometimes you want to throw away everything you have in favor of everything they have. That's easy enough:

git reset --hard origin/master

(while on your own master). Be careful with this command as it does something you cannot undo! In particular, the --hard step discards uncommitted work-tree changes and you cannot get those back. The git reset step also says "I don't want my current branch name (whatever that is, er, I think it's master) to save my commits any more, I want it to remember only their origin/master commits." So now your current branch name (you think it's master) only remembers the same commits as origin/master. Better check and make sure your current branch name really is master, eh?

(If it's not, those commits are recoverable for a while, unlike unsaved work-tree work.)

Note that when you do this git reset, you have just moved your own master in a potentially-undisciplined way. Maybe you're the office prankster. :-)

Answer 3

Yes, you can force to pull by git pull -f origin master:master.

Also, you can compare the latest commit id between server and local master branch.

Answer 4

At first, make sure your fix-changes are in remote/master.

$ git fetch
$ git checkout master
$ git pull origin master

$ git diff master..origin/master         # see if there is any difference between 'local-master' and 'remote master' 

N.B. git log shows all the commit history. Go to your GitHub repo using Browser and see if the last commit is same of remote/master & local/master.