Back out a commit to origin/master

Question

I'm relatively new to git, and I think I broke my master. Hopefully, someone can help me untangle it.

I have my master on GitHub, and local master and tracking branch on my dev system. I also have the master on my QA system.

On my dev system, I committed my local branch and merged it into (local) master, then pushed master to origin/master at GitHub. Then, I pulled master to the QA system. Then, I made some further changes to my local branch.

What I did was:

dev branch -- merge --> dev master
dev master -- push --> GitHub master -- pull --> QA master

I think I should have done:

dev **branch** -- push --> GitHub **branch** -- pull --> QA **branch**

Is that right?

Now: I want to revert the QA and GitHub master back before the commit ... in effect, back out that whole merge. Then, I want to push the branch (not the master) up to GitHub, and pull the branch to QA.

1. How do I revert the masters on QA and on GitHub?
2. Do I also need to revert the master on development?
3. How do I preserve the branch changes I've made on development?

Help, please?

Answer 1

Should you have pushed a branch instead of merging to master?

That's a good question. If the commit was highly experimental, then pushing a branch probably would have been better. Otherwise, if you had a high confidence in the commit, then merging to master was correct. No need to pollute your workspaces with remote branches if you don't have to.

Let's assume you want to switch this commit to a branch and push it remotely. I'll draw a commit graph for this scenario:

A-C-D
 \   \
  B---E < master, your_branch

Let's say master was at B, and C & D where made on your_branch. E is the merge commit for the two. On to your questions. You revert master on GitHub & QA by fixing your local repository, and then forcing GitHub in particular to match it. So actually your questions are best answered in reverse order.

First we fix your_branch

git checkout your_branch
git reset --hard D

This will move branch to D, yielding:

A-C-D < your_branch
 \   \
  B---E < master

Now we fix your local development master

git checkout master
git reset --hard B

Which gives:

A-C-D < your_branch
 \
  B < master

Good-bye, unwanted merge commit E.

Fix GitHub (and QA)

git checkout master
git push -f

This will force master on GitHub back to B. If you were collaborating with other devs, they would hate for this as you're re-writing history. But since this presumably your personal repository without collaboration, go for it. Now to make a remote branch:

git checkout your_branch
git push origin your_branch

Now that GitHub has been fixed to match development, updating QA should be a simple:

git checkout master
git pull
git reset --hard origin/master  # I'm assuming master will be on an orphaned commit after the pull

Answer 2

To me, the initial question seems like a matter of personal workflow preference of whether you want the development branch to already be merged into master by the time it hits the QA system. As for your current predicament, my (not-so-necessarily the best) suggestion:

1. In your local master, git revert <merge-commit>, reverts the changes introduced by your development branch merge. Push the local master up. Pull that across to QA. After this, master across all repositories should be at the same history state.
2. As per the above point, to maintain repository consistency I would do so, yes.
3. Before doing your revert, stash your changes (cf. git stash). After completing the entire revert process, pop the changes (cf. git stash pop).

Hope you find that useful.