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
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.
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+
如果合并提交仍然是最新的,并且您还没有将该提交推回上游,则git reset --hard HEAD^
应该使您回到合并之前的提交-即将您的master
分支返回到git merge origin/master
之后的位置git merge origin/master
。
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.