Question

I have a feature branch where I have some commits. Then I did run git rebase master and merged that branch back to master.

So it was like

git checkout -b somebranch
......some work commits here .....
git checkout master
git fetch
git merge origin/master
git checkout somebranch 
git rebase master
git checkout master
git merge  somebranch

Now I need to pull out all my commits in somebranch out from master completely, possible will need to merge it back to master later.

Update: changes were pushed to master some time ago and there is many commits after merge, so reset to head will not work

Was it helpful?

Solution

git checkout -b somebranch # from "A"
......some work commits here x, y, z .....
git checkout master
git pull # call new HEAD "B"

So we have something like

A -> a1 -> a2 -> B <= master
 \
  x -> y -> z      <= somebranch

and then:

git checkout somebranch 
git rebase master

A -> ... -> B <= master
             \
              x' -> y' -> z' <= somebranch

git checkout master
git merge  somebranch # call new HEAD "C"


A -> ... -> B -------------> C <= master
             \              /
              x' -> y' -> z' <= somebranch

So, at this point, you can easily undo your unwanted merge, by just rewinding master to B. However, once you push C (and other people have seen it, and/or done work on top of it), this becomes hard.


The simple solution is to just revert all commits on somebranch:

git revert x'..z'

and push.

Now, before you can merge somebranch again, you'll have to rebase it (like you did originally). This works, but you do end up with some noise in the history of master.


If a limited number of people have seen and/or committed children, and you can coordinate with them, it's possible to avoid this, but it's a lot of work. You have to make sure everything they're working on is committed and pushed if possible, and then you can rebase this:

A -> ... -> B -------------> C -> c1 -> c2 -> D <= master
             \              /
              x' -> y' -> z' <= somebranch

to this:

              c1' -> c2' -> D' <= master
             /
A -> ... -> B -------------> C -> c1 -> c2 -> D
             \              /
              x' -> y' -> z' <= somebranch

Now the middle branch will be orphaned, the new head D' doesn't have your changes, and somebranch is still intact so you can merge later.

To do this, use:

git rebase --onto B C c1
git push --force

Everyone else will now have to update to the new head D', for example by doing:

git fetch
git checkout master
git reset --hard origin/master

Note that if anyone does have local commits that still depend on C (and aren't already visible in the c1..D chain when you rebase), they'll need to rebase or cherry-pick them across to the new history. This is potentially a lot of (error-prone) work, so better to avoid if possible.

OTHER TIPS

On local copy of master you can try the following which will create a new commit with the reverted changes (the reverse of what you have already done on master).

git revert OLDER_COMMIT^..NEWER_COMMIT

where OLDER_COMMIT is the first commit of your feature branch commit and NEWER_COMMIT is the last commit of your feature branch.

Or alternatively, you can try

git revert -n OLDER_COMMIT..NEWER_COMMIT

which will revert the changes done by commits but does not create any new commit with the reverted changes. The revert only modifies the working tree and the index.

Note: with use of 1.7.4+

If the merge commit is still the latest, and if you have not yet pushed that commit back upstream, git reset --hard HEAD^ should put you back on the commit before the merge - i.e. return your master branch to where it was after git merge origin/master.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top