14

I'm using git flow for my projects. When a release has been merged into the master branch it is tagged with the release version (e.g. 1.2.0) and deployed to my production servers.

Now I want to quickly revert to the previous release tag (e.g. 1.1.0) as the deployment should not have happened.

Elaboration:

  • I merge the 1.2.0 release branch into the master branch.
  • I tag the master branch with 1.2.0.
  • I push my local repo to the origin.
  • I conclude that I released too early.
  • I want to revert back to the state of master where it was tagged as 1.1.0.
  • I want the master @ origin to revert back to the 1.1.0 state as well.

enter image description here

How would I do this?

Kriem
  • 8,666
  • 16
  • 72
  • 120
  • Possible duplicate: http://stackoverflow.com/questions/16081260/revert-merge-git-flow/ – 1615903 Apr 25 '13 at 09:41
  • Not really a duplicate. I read that post but it doesn't answer my question. They are talking about resetting the dev brnach. I don't want that. My master branch is tagged with releases. I just want to fall back to a previous tag in my master branch. – Kriem Apr 25 '13 at 09:42
  • 1
    `git checkout v1.1.0` would take you back to the previous release - is that what you're looking for? – 1615903 Apr 25 '13 at 09:44
  • I can checkout the master branch, but that's not enough. How would I let the origin know that I want this commit to be the 'active' one? – Kriem Apr 25 '13 at 10:36
  • 1
    By doing the reset for the master branch and then doing `git push -f` just as described in the link I provided – 1615903 Apr 25 '13 at 10:44
  • But I would lose the 1.2.0 commit, wouldn't I? – Kriem Apr 25 '13 at 11:11
  • Yes you would. Is that not what you wanted? _deployment should not have happened_ you said in your question. Also, what do you mean by _letting the origin know that I want this commit to be the 'active' one_? Origin is a bare repository, there's no workspace, so there's no checked out branch there. Please elaborate a bit more. – 1615903 Apr 25 '13 at 11:44
  • Sure thing. I'll update the question. – Kriem Apr 25 '13 at 12:01
  • @user1615903: would he really LOSE the commit, or would the commit be just detached (and i.e. stay visible in reflog and be ready to be reattached and further worked upon)? – quetzalcoatl Apr 26 '13 at 09:08
  • @quetzalcoatl It would be detached yes, until it gets garbage collected, so he would eventually lose the commit. – 1615903 Apr 26 '13 at 09:12
  • @Kriem where is that screenshot coming from? Is it a visualization tool or did you create it manually? – acme Jul 07 '14 at 07:54

2 Answers2

9

Assuming you want to keep the history, but undo the changes the 1.2.0 release did. Use git-revert to create a new commit that reverts everything 1.2.0 did:

git checkout master
git revert HEAD
1615903
  • 32,635
  • 12
  • 70
  • 99
  • Do I lose the 1.2.0 tag? In other words, do I lose the point in history where I created the 1.2.0 tag at the master branch? – Kriem Apr 25 '13 at 12:17
  • No. This will keep everything in place - it adds a new commit after 1.2.0 tag. – 1615903 Apr 25 '13 at 12:17
  • 2
    @Kriem Tags are separate pointers not related to branches (which are just pointers themselves). So changing a branch will not change tags. – poke Apr 25 '13 at 12:18
  • @poke - I'm afraid I don't really understand. – Kriem Apr 25 '13 at 12:31
  • 2
    I can't revert: `Commit ... is a merge but no -m option was given.` – Kriem Apr 25 '13 at 13:21
  • 1
    @Kriem Branches and tags are just pointers or labels for commit objects (the things with that hash, e.g. 17813ace…). When you commit, the branch pointer moves to the new commit object, so branches are somewhat “dynamic” pointers. Tags are such pointers as well, but usually you would not want them to move; they are meant to stay the way they are forever (so you have an always valid reference to the *same* version). Now just because you move a branch, i.e. make it point to something else, a tag that points to something won’t change. They are completely unrelated in that aspect. – poke Apr 25 '13 at 15:28
  • @poke I'm beginning to understand. Thanks for your explanation. – Kriem Apr 25 '13 at 17:43
  • Pretty old stuff here, but I find the accepted answer very misleading. In my opinion code versioning and release management are two orthogonal problems. You should be able to deploy any version to production at any time without messing with your branches. – Ricovitch Aug 07 '20 at 07:49
  • @Ricovitch the question is specifically about the "git flow" workflow. – 1615903 Aug 09 '20 at 11:32
0

If you want to remove your last commit and its history, you must use git commands:

(git checkout develop)
git reset HEAD^ --hard
git push origin -f

git checkout master
git reset HEAD^ --hard
git push origin -f

This remove the last commit in master and develop and their history, including the tags.

Elbrujodelatribu
  • 101
  • 2