Git：如何在合并前返回

Question

Thanks for your help. I am really confused...

I merged a pull request for a team mate.

Now I wish to go back to the situation before the merge, because I have realized that bugs are introduced. The pull request was done by a friend on the 24, I did the merge on the 24.

• I need to go back to the situation of the 20.
• what will happen to the changes done by the team mate? Will I be able to see/use them again?

Thanks!!!

commit ff1e9ecfa13c5050957b77bd5b5695d802415867
Merge: 053c894 437e11c
Author: me
Date:   Tue Mar 24 09:06:11 2015 +0100

Merged ' changes on xxx

commit 437e11c23ae7da68f8bb3698557bdc2aa3d9a614
Merge: a129401 adfd8c5
Author: someone else
Date:   Tue Mar 24 00:00:18 2015 +1000

Merge pull request #17 from 

xxx

commit adfd8c5c30541095ee48ce64da14740f92594ec8
Author: someone else
Date:   Mon Mar 23 23:54:06 2015 +1000

xx

commit 053c89426460ffaa86873bed342bc38e24a13096
Merge: 849ec63 35fdbc6
Author: me
Date:   Fri Mar 20 07:57:13 2015 +0100

Answer 1

Assuming you didn't delete the branch on which the original changes appear, then the work from your teammate is still sitting on that branch, so I wouldn't worry about losing those changes so long as you still have that branch where the changes were made.

You can do a git reset --hard [commit hash] to go back to the commit before the merge, and it's like traveling back in time. However, you'll also undo any changes that were added after the commit you specify in the reset command, if you have any.

Ex:

On my current branch I have the following commits:

A
|
B    <- commit *before* the merge
|
|
|  --- some other branch
| /
|/
C    <- commit where "some other branch" was merged into current branch
|
D
|
E

If I do git reset --hard B then I'll go back to the commit before the merge at C . But I'll also lose commits D and E in the process. Once you do that, just check the state of the branch and make sure it looks the way you need it to, then do a git push --force , which will update the remote repo to this state. The reason you need --force is because you'll be deleting commits D and E from your current branch on the remote repo, and git won't let you do that without the --force option, since you're asking it to delete work.

---

Depending on how substantial these changes are, sometimes it's easier to just roll forward and fix the bugs, than to try to undo the changes. Where that line is (to go forward or back) is a case-by-case decision.

Answer 2

Your teammate's commits are in your repository, along with the merge commit you made. You can put the labels back where they were before the merge, and if you want to reference your teammate's commits in the future, add a new label.

Something like this, right? I think I've got the labels close enough:

   ...053---ff1    master
           /
 ...a17---437      teammate
         /
     ...adf        other

To reset labels, if your most recent checkout wasn't master you just force the label to a new place. Otherwise you have to check out another reference first (or a plain commit) or make the checkout follow along.

You want master back at the first parent of the merge, and having it checked out wouldn't be so bad either, so:

git tag wip
git checkout -B master master^1

and now master refers to 053 , wip refers to ff1 , and nothing else has changed. The wip reference lets git know you're still referencing it and its history. You've got the master commit from before the merge checked out and master is back to referring to that. The force-relabel-and-checkout git checkout -B $commit $ref has a shortcut if you're moving your current checkout, git reset --hard $ref .

If you don't have or want master checked out:

git branch -f master master^1

and that skips all the worktree churn.

If you move a label and you realize you really should have tagged the old commit first, you can refer to it through the reflogs, either the label's previous target or your previous checkout, depending: git tag wip @{1} to tag your previous worktree commit and git tag wip master@{1} to tag the previous master commit. git revisions shows all the ways you can refer to commits, from the number of them you might guess people wind up not bothering with temporary names all that much and just refer to commits used by inflight work directly, and that's exactly right.