Question

I have a repo that I’ve been using with GitHub. Previously, the repo had only 1 branch (i.e. master) and was fully up-to-date with the remote repo, but having done 2 local commits of new experimental work, I decided that what I wanted to do was create a new branch with those 2 commits on a “dev” branch which would still be accessible on GitHub as an alternative branch.

Therefore, I did the following:

git branch dev             # create new branch
git reset --hard HEAD~2    # roll back 2 commits on HEAD
git checkout dev           # make dev the active branch

Locally, all is now good. I now have my two local branches: master (which is 2 commits behind — on the stable version) and dev (HEAD) which is on the current experimental work.

However, on the GitHub side, all is not well: I have two branches, master (HEAD) and dev, however both of them are exactly the same (i.e. the two latest commits are on the master branch, when actually I only want them on the dev branch).

So just to summarise, if we call the latest unstable commit (dev work), commit 10, and the stable commit number 8, then we have the following:

10 – dev, origin/master, origin/dev, origin/HEAD

9

8 – master

So the question is how I get origin/master to correctly point to commit 8. (And also I’m confused by the role of origin/HEAD in all of this…)

Answer 1

If you want to change the history of master, you need to git push -f origin master in order to make GitHub record the new HEAD for master. (Make sure to warn any collaborator of that change: they need to reset their local master branch to that new HEAD).
Pushing dev wasn’t enough.

origin/HEAD reference the HEAD of the remote GitHub repo (which should be origin/master, unless you explicitly changed it through the GitHub repo Admin interface).