3

I know this question has been asked before but although the given answer git reset --hard HEAD~1 works, I cannot push it to the server since the server is ahead. Pulling obviously puts me right back where I was.

How do I reset the server?

Luke Puplett
  • 42,091
  • 47
  • 181
  • 266
  • 1
    use `git revert` and push. – Mali Sep 26 '13 at 09:14
  • 3
    Obligatory PSA: pushing changes that rewrite history is considered uh... "antisocial". Git only lets you do this out of the goodness of its heart, not because it's a good idea. – millimoose Sep 26 '13 at 09:15
  • Right. So how does anyone rollback? Isn't that the point of source control, to undo your cock ups? – Luke Puplett Sep 26 '13 at 09:17
  • 2
    Unfortunately, the point with git is that it works with local repositories mainly. Therefore, if someone pulled the remote before you rewrite the history (aka: you push `HEAD~1` but there is a colleague who already has `HEAD`) he will have to push rewriting the history himself, therefore re-introducing the changes you reverted. So, don't `git reset --hard HEAD~1 && git push --force`, but reset manually (reintroducing the chances one by one, then `git push`) – ThanksForAllTheFish Sep 26 '13 at 09:28
  • Got it. Makes total sense - `git revert` is the proper way I see now. Wouldn't life be wonderful if Git was designed with a UX team based around scenarios. – Luke Puplett Sep 26 '13 at 13:11

3 Answers3

5

It all depends on the project's conventions. The safe bet is to use git revert because you can always drop the commit later if that's the policy. If you want to revert a merge, you need to specify which parent you want to revert to ("mainline") with git revert --mainline <parent-number>.

You should ask the project's maintainer to explain what to do in your specific case.

In our team, we use the following set of rules:

  • Only pull using rebase (branch.autosetuprebase=always)
  • master is the only "public" branch
  • Development branches remain "private" even when pushed to our shared server

This means everybody is free to do whatever they wish with their private branches, you can rebase or drop commits as you feel fit. On the other hand, our shared server is configured to refuse forced pushes to master.

That is not to say we never reset master, sometimes (maybe once a year) someone might accidentally push a merge where we think that it would terribly screw up our history. In these exceptional cases one of our git-gurus will write an email to the whole team, explaining what is about to happen and what steps to take to update local clones.

Tobias
  • 6,388
  • 4
  • 39
  • 64
3

You want to force a push. Only use this if you are certain of the change.

git push origin --force
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Oliver Atkinson
  • 7,970
  • 32
  • 43
  • This works, but what if someone else has already pull the history? He will not be able to push WITHOUT rewriting himself – ThanksForAllTheFish Sep 26 '13 at 09:25
  • @mardavi thats correct - the other person could `cherry-pick` their commits - maybe its worth looking into that. Why dont you just make another commit which fixes the changes you want removed, that way your friend wont need to do that. – Oliver Atkinson Sep 26 '13 at 11:36
  • Oliver's answer immediately solved the problem, although please look at VonC's answer since it reflects what I should have done. – Luke Puplett Sep 26 '13 at 13:09
2

Force pushing is an option, if your colleagues accepts to reset their own local branch to the new origin/master (assuming we are talking about that 'master' branch).

git fetch
git reset origin/master

(not a reset --hard, because that would wipe out work in progress and private file)
(note that it will unstage whatever was already added to the index)

The other option, "to undo your cock ups" (if you have already pushed the wrong commit), it to revert it, creating a new one which cancel the previous one.
See git revert.

You can then push (regular push) that revert commit.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    Reverting is generally the safe and correct way to undo changes. It’s equivalent to all the revert/undo mechanisms in other VCS and will keep both the wrong commit and the fact that you reverted it in the history. – poke Sep 26 '13 at 10:27