0

I made a few unstable commit changes that were also pushed. My imaginary commit tree is as follows:

A -> B -> C -> D

Commit "A" was the latest stable commit. Upon finding that the later changes were unstable, I went back to the last stable revision using

git checkout A

I then created a new branch "stable" with

git checkout -b stable

And continued working in that branch. Now I want to merge to master, but I don't want to delete the changes I previously had, so I wanted to add them to a new branch instead of using revert. Following the advice in this thread, I did the following from the master branch:

git branch unstable

git reset --hard HEAD~3

So now HEAD points to commit A, and the new branch "unstable" starts at commit B. But I want to merge my stable changes (in branch "stable") so I use

git merge stable

And it completes successfully with no conflicts, and HEAD now points to the latest revision with the the stable changes merged in. I can now push all branches to my repository except master, which reports a non-fast-forward error. If I pull, it seems to pull all the unstable changes I had from earlier.

There appears to be a large number of posts similar to this, but it seems that mostly people want to just use revert to undo the commits they had, whereas I want to keep my unstable commits, but in a separate branch as I have it now. What am I doing incorrectly?

Community
  • 1
  • 1
doubleshot
  • 85
  • 2
  • 4

1 Answers1

1

The key question here is whether anyone else is using your master branch, and might already fetched that version. If not, then it's safe for you to do a "forced" push, which will overwrite the old version of master. You can do that with:

 git push -f origin master

However, if anyone might have used the master branch, you don't want to rewrite public history. In that case, you can do:

 git fetch origin
 git merge -s ours origin/master
 git push origin master

The "ours" merge strategy says to create a merge commit, but ignore all the content that you're merging in (i.e. your old master branch). Then your history will contain the history of master in origin, so you'll be able to push it without having to use the -f (--force) option.

Your unstable branch will still exist locally in both cases, of course.

Mark Longair
  • 446,582
  • 72
  • 411
  • 327
  • Thanks for your quick response, Mark; I had forgotten to reply. I was ironically contacted back around the time you posted by someone I had called for help previously and we were able to get the situation resolved by fast-forwarding the "unstable" branch (which, along with origin/HEAD, pointed to commit D), and completing a merge of "stable" into "master" with a method similar to what you described here. I didn't have anyone else working on it at the time, thankfully, but I didn't have to --force it either. – doubleshot Oct 17 '11 at 17:58