Git pull into wrong branch

Question

Myself and one other developer had been merging and pushing our work to a non-master branch called toolwork. That way, we didn't impact the rest of the team. My topic branch was called DPM-93 and my git workflow was this.

# do some work
git checkout DPM-93
git commit -m "did some work"

# catch up
git checkout toolwork
git pull origin toolwork

# rebase my topic branch
git checkout DPM-93
git rebase toolwork

# merge and push my changes
git checkout toolwork
git merge --no-ff DPM-93
git push origin toolwork

That was mostly working fine until I accidently issued these git commands

git checkout toolwork
git pull origin master

At that point, a bunch of new stuff showed up in branch toolwork and I'm not sure how to get rid of it short of deleting my workspace and re-cloning from the repo.

Is there any way to back this out to the state before the pull?

score 125 · Accepted Answer · edited May 23 '17 at 10:31

git reset --hard ORIG_HEAD

From the git reset man page (if you just did the pull):

Undo a merge or pull

$ git pull                         (1)
Auto-merging nitfol
CONFLICT (content): Merge conflict in nitfol
Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard                 (2)
$ git pull . topic/branch          (3)
Updating from 41223... to 13134...
Fast-forward
$ git reset --hard ORIG_HEAD       (4)

Try to update from the upstream resulted in a lot of conflicts; you were not ready to spend a lot of time merging right now, so you decide to do that later.

"pull" has not made merge commit, so "git reset --hard" which is a synonym for "git reset --hard HEAD" clears the mess from the index file and the working tree.

Merge a topic branch into the current branch, which resulted in a fast-forward.

But you decided that the topic branch is not ready for public consumption yet.
"pull" or "merge" always leaves the original tip of the current branch in ORIG_HEAD, so resetting hard to it brings your index file and the working tree back to that state, and resets the tip of the branch to that commit.

See HEAD and ORIG_HEAD for more.

Would it be okay to use `git rebase -i ORIG_HEAD` to delete the unwanted commits, assuming no one has yet pulled from master? — unutbu, Oct 22 '10 at 17:28
@unutbu: I believe the end result of such a rebase would be similar to a `git reset` in this case. — VonC, Oct 22 '10 at 18:42
Thanks, @VonC. Sorry for the silly question. Somehow I didn't realize that `git reset --hard` not only alters the working tree and index but also removes the parent pointer in the DAG. — unutbu, Oct 22 '10 at 20:34

score 99 · Answer 2 · edited Mar 15 '17 at 03:16

99

Reset the master branch:

git reset --hard origin/master

edited Mar 15 '17 at 03:16

Community

1
1

answered Sep 22 '11 at 22:53

HoBa

3,442
5
26
33

11

Not sure if this is due to the "correct" answer being 2 years old, but after trying the other suggestions with no luck, this is what worked for me. – Levi Rosol Jun 27 '12 at 23:07
5

this solved the problem I had which is that I had pulled into the wrong branch – HorseloverFat Dec 04 '13 at 10:26
2

Worked for me. Thank you – Glen Jan 06 '16 at 09:25

score 11 · Answer 3 · answered Oct 22 '10 at 16:29

11

You can use git log to find the SHA-1 of the revision you want to be at the head of your toolwork branch, then use git reset --hard <SHA1> to revert your working copy to that revision.

Back everything up first! And re-read the man page for git reset to make sure it's doing what you want.

EDIT: Oh yes, ORIG_HEAD should contain the right SHA-1. But check first.

answered Oct 22 '10 at 16:29

Cameron Skinner

51,692
2
65
86

Didn't see you answer at first. `git reset` is right (even though a bit dangerous as you rightfully mention). +1 – VonC Oct 22 '10 at 16:37
Prefer this answer, since you're more explicit about which commit you want to revert to. In my case, this was useful since I had a couple of local commits before I accidentally pulled the wrong branch, so I didn't want to do a hard reset to ORIG_HEAD. – Joseph Humfrey Apr 08 '12 at 18:41

score 7 · Answer 4 · edited May 23 '17 at 12:18

I did a similar thing recently, and used a simpler solution based on this answer.

Assuming that the state of the toolwork branch that you want to revert to has been pushed to origin, you can simply do

git fetch origin
git reset --hard origin/toolwork

In my case, the value of ORIG_HEAD had been overwritten by another merge on a different branch, and doing this I didn't have to worry about searching for the correct commit in the log.

score 2 · Answer 5 · answered May 16 '18 at 14:04

What worked for me is simply

git reset --hard

I did this from the local repository with the unfortunate merge/pull:

Laptop@LAPTOP-xxxxxxxx /d/Google Drive/xxxxxxx/Github/xxxxx (staging_ec2|MERGING)
$ git reset --hard
HEAD is now at 2d5a511 [last commit comment]

Laptop@LAPTOP-xxxxxxxx /d/Google Drive/xxxxxxx/Github/xxxxx (staging_ec2)
$

score 2 · Answer 6 · edited Apr 16 '21 at 09:35

2

Step 1:

git log

git reset --hard <hash>,

The hash is something like 0928817nsbn78867hs3g5666

Example: if you git log, you will get:

commit 0928817nsbn78867hs3g5666 (HEAD -> yourrepo, origin/yourrepo)

Step 2:

git reset --hard 0928817nsbn78867hs3g5666

edited Apr 16 '21 at 09:35

William Baker Morrison

1,642
4
21
33

answered Apr 15 '21 at 13:53

Mercy Jemosop

21
2

score 0 · Answer 7 · answered Mar 25 '20 at 12:25

0

You can abort that merge using below command

git merge --abort

It will simply undo the accidental pull...

answered Mar 25 '20 at 12:25

Abdul Yasin

3,480
1
28
42

Git pull into wrong branch

7 Answers7

Linked