Git pull into wrong branch

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

  • Prepend a commit from master to a branch
  • git diff of current version with branching commit
  • “if” versus “switch”
  • GitHub: How to send one pull request per separate commit?
  • git root branches… how do they work?
  • Why doesn't git allow me to safely delete a branch?
  • 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?

  • Unable to use Gcommit (Fugitive Plugin) on Vim when signing commits
  • npm install from Jenkins fails installing module hosted on bitbucket
  • How to create a new git repository with a file that is already in a git repository, keeping the commits
  • Can the git tree hash be used to uniquely identify a specific state in a subdirectory
  • Git - checkout a single directory out of a repo - error: pathspec did not match any file(s) known to git
  • git push shows wrong username
  • 4 Solutions collect form web for “Git pull into wrong branch”

    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)
    
    1. 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.
    2. 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.
    3. Merge a topic branch into the current branch, which resulted in a fast-forward.
    4. 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.

    Reset the master branch:

    git reset --hard origin/master
    

    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.

    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.

    Git Baby is a git and github fan, let's start git clone.