Git, How to reset origin/master to a commit?

Question

I reset my local master to a commit by this command:

git reset --hard e3f1e37

when I enter $ git status command, terminal says:

# On branch master
# Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded.

#   (use "git pull" to update your local branch)
#
nothing to commit, working directory clean

Since I want to reset origin/header as well, I checkout to origin/master:

$ git checkout origin/master
Note: checking out 'origin/master'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 2aef1de... master problem fixed for master. its okay now.

and reset the header by this command:

$ git reset --hard e3f1e37
HEAD is now at e3f1e37 development version code incremented for new build.

Then I tried to add commit to origin/header that I was not successful.

$ git commit -m "Reverting to the state of the project at e3f1e37"
# HEAD detached from origin/master
nothing to commit, working directory clean

Finally, I checkout to my local master.

$ git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Since, I reset the head of origin/master I expect local and origin should be in same direction but as you see, git is saying that my local/master is behind origin/master by 7 commits.

How can I fix this issue? The things that I'm looking for is Head of local/master and origin/master point to same commit. Following image shows what I did. Thanks.

Solution 1

origin/xxx branches are always pointer to a remote. You cannot check them out as they're not pointer to your local repository (you only checkout the commit. That's why you won't see the name written in the command line interface branch marker, only the commit hash).

What you need to do to update the remote is to force push your local changes to master:

git checkout master
git reset --hard e3f1e37
git push --force origin master
# Then to prove it (it won't print any diff)
git diff master..origin/master

Solution 2

The solution found here helped us to update master to a previous commit that had already been pushed:

git checkout master
git reset --hard e3f1e37
git push --force origin e3f1e37:master

The key difference from the accepted answer is the commit hash "e3f1e37:" before master in the push command.

Solution 3

Assuming that your branch is called master both here and remotely, and that your remote is called origin you could do:

git reset --hard <commit-hash>
git push -f origin master

However, you should avoid doing this if anyone else is working with your remote repository and has pulled your changes. In that case, it would be better to revert the commits that you don't want, then push as normal.

Solution 4

Since I had a similar situation, I thought I'd share my situation and how these answers helped me (thanks everyone).

So I decided to work locally by amending my last commit every time I wanted to save my progress on the main branch (I know, I should've branched out, committed on that, kept pushing and later merge back to master).

One late night, in paranoid fear of loosing my progress to hardware failure or something out of the ether, I decided to push master to origin. Later I kept amending my local master branch and when I decided it's time to push again, I was faced with different master branches and found out I can't amend origin/upstream (duh!) like I can local development branches.

So I didn't checkout master locally because I already was after a commit. Master was unchanged. I didn't even need to reset --hard, my current commit was OK.

I just forced push to origin, without even specifying what commit I wanted to force on master since in this case it's whatever HEAD is at. Checked git diff master..origin/master so there weren't any differences and that's it. All fixed. Thanks! (I know, I'm a git newbie, please forgive!).

So if you're already OK with your master branch locally, just:

git push --force origin master
git diff master..origin/master

View more solutions

Comments

[DarmVillegas]

First of all, make sure you are allowed to force push code to a protected branch on your project, otherwise you won't be able...

[mnagel]

that does the requested operation, but keep in mind that it will make unhappy those people who already pulled the commits from master.

[Daniil Shevelev]

I followed this steps and it rolled back. But the origin/HEAD is now pointing to a branch other than master. What can I do to fix this?

[Simon Boudrias]

You shouldn't care about origin/HEAD, simply push the good ref to origin/ref

[Nick W.]

Agreed, had to do this today after accidentally merging the wrong branches together then pushing to origin. It works well, but it could be very disruptive if other people have been checking out the affected branches from origin. Use with caution.

[m0skit0]

Doesn't work. remote: error: denying non-fast-forward refs/heads/master (you should pull first)

[m0skit0]

Doesn't work: remote: error: denying non-fast-forward refs/heads/master (you should pull first)

[Simon Boudrias]

@m0skit0 It does work. It is your git server who's doing custom magic with git-hooks. This mean you won't be able to reset origin/master. Your only option is to revert changes in a new commit.

[m0skit0]

Erm... No, it doesn't work. I cannot revert all changes because then it says there's a merge. And if I use -m I got the message posted. git push origin :master, reverting to commit I want origin to have and pusing it, did work though.

[Simon Boudrias]

@m0skit0 reverting in git words mean creating a new commit on top of a branch changing back the chances introduced in an older commit. So it doesn't change the history of a branch. You can also just ask the person in charge of your git server to re-allow non-fast-forward commits.

[m0skit0]

Yes, I know. In this case I don't mind losing the history because all commits are in fact a merge from another branch. I am in charge of the git server and I don't want to allow non-fast-forward commits.

[intuitivepixel]

@m0skit0 as the message say's you should pull first :)

[HankCa]

The answer to this is at stackoverflow.com/a/10544328/1019307 - git config receive.denynonfastforwards false but actually I set that manually in my local git repository I have in /opt/git that I created to play with the ideas here. I'm not sure how or if can do this for bitbucket, github etc... And @intuitivepixel that is pointless as it reverse what you were trying to achieve with the hard reset.

[KarenAnne]

Hi @jkovacs, I don't want new changes in master to be removed. I just want to push that commit hash "e3f1e37" to origin master. Is it possible by skipping the 2nd command git reset --hard "e3f1e37"?

[KarenAnne]

Hi @jkovacs, I just confirmed that I can skip the 2nd step. :)

[BadHorsie]

After doing this, I have two tagged commits ahead of where I reset master to, which didn't go away. How do I delete those entries?

[entpnerd]

On my machine, it appears to blow away the actual previous pushes you were undoing. For example, after doing the forced push, all future entries in git log are no longer there, so I see no way of recovering the code changes that were undone.

[Simon Boudrias]

@entpnerd check git reflog to find the commits you deleted.

[entpnerd]

@SimonBoudrias when I execute git reflog I only see the commits before the reset point in addition to the reset and rebases that were performed by the git reset command. Also, when I check SourceTree, I don't see the commit ID of the pushes to the origin that happened after the reset point. It's like they never happened. That being said, your solution does correctly reset the origin. From my point of view, I just don't the retention of reseted commits, but it did work. :-)

[Sean Malter]

NOTE: you lose your local commits

[Max MacLeod]

@SeanMalter commits are never lost. Although it may be that they are no longer in the ancestor hierarchy.

[Keith Pickering]

This is the way to do it if you seriously fubar'd your branch, you just want it back to a workable state, and nobody else is working on it remotely.

[Thiago]

It may be easier if you manually delete that branch from origin, before pushing the edited branch.