0

I know this has been answered elsewhere at length, but I just need a simple answer... I can't understand the long discussions elsewhere.

This is the situation:

  1. Dev machine - pushes changeset X to head.
  2. Production machine - pulls changeset X. Production machine breaks.
  3. Developer panics, wants to revert to changeset X-1 on production machine, WITHOUT deleting changeset X.

What is the simple way to do this on the production machine?

Thanks.

UPDATE: I should have been searching for "roll back" a changeset, not "revert"! So should you if you are in the same situation - i.e. you want to return to a particular commit locally, without altering git history.

Community
  • 1
  • 1
Richard
  • 62,943
  • 126
  • 334
  • 542
  • 1
    NB: I think the answer to this should be added to http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide?rq=1 – Richard Jun 06 '13 at 11:23
  • I'm not sure if using the term `revert` is confusing, given that it has a particular meaning in git. Basically I mean: check out an earlier changeset locally, without deleting later changesets from git history. – Richard Jun 06 '13 at 11:25
  • 1
    "In words of one syllable" is an unrealistic requirement. If the deployment to production caused problems then the deployment should be rolled back. If you don't have a release process that defines how to do this then now is the time to create one. – CB Bailey Jun 06 '13 at 12:05
  • I've deleted "words of one syllable" from the title. I was just frustrated because all the other answers are very long and technical. Seems to me like this is a common requirement for newbies, and I just wanted a quick answer. – Richard Jun 07 '13 at 09:03
  • As I note in the comment above - given my requirements, perhaps the word "revert" is misleading. Maybe I should have been using "roll back" instead. – Richard Jun 07 '13 at 09:05

2 Answers2

1

Well, you can use a tag to reserve a ref to commit X:

git tag commit_X -m 'this is the commit that causes problem'
git reset --hard HEAD^
git push --tags
git push -f

And later if you want to checkout commit X and see what's going on there, simply use that commit_X tag to bring back the changeset.

neevek
  • 11,760
  • 8
  • 55
  • 73
0

OK, this seemed to work: 

git log | more

Then find the entry you want to go back to, e.g.:

commit 4facf8fc299a545557b4a47a61ed876efe55eab6
Date:   Thu May 30 19:17:32 2013 +0100
Fix syntax error

Then type: 

git checkout 4facf8fc299a545557b4a47a61ed876efe55eab6
Richard
  • 62,943
  • 126
  • 334
  • 542
  • 2
    This doesn't revert anything. It moves you to that commit in time, and leaves you in what's called a "detached head" state, i.e. not on a branch (aka "branch head"). You can't commit from that point, as there's no branch head there. You're basically visiting a point in time, but are unable to affect it. It *will* change the working tree to that point in time. If all you're after is getting the files how they were at that point for something that needs to read them, then it'll work. Afterwards you should `git checkout branchname` to get yourself back on the original branch. – Gary Fixler Jun 06 '13 at 11:45
  • @GaryFixler you actually **can** make commits from a detached head state, there's just no branch pointer, so unless you make one, as soon as you `checkout` another line of development, you won't be able to easily go back to the last commit you were at unless you use the reflog. –  Jun 06 '13 at 14:39