Working with WordPress we do all the upgrades on our development environment and push the changes to the repro. From the repro when then do a pull to update the clients staging host, we did a full test both manual and automatic.
The update was to move from WordPress 4.3 to WordPress 4.4 and update it to standard plugins. The client did the UAT and signed off, we then promoted to production. After a few days, the client reported an issue with re-directs not going to the correct pages. So something was broken with the update, we rolled back the production to the previous working repro version.
Meanwhile, we had committed additional updates to the repro that was waiting to be pulled to the staging, so we had mismatch on our repro and we were now faced with rolling back the repro to the version we currently running on production.
The whole process started with rolling back the development environment to the current working version. The first we had to do, was to stash away any changes we have done on the development, we did that with the command.
You use “stash” when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.
Next we rolled back the development environment to the latest version, we did that using the command:
We used “tag” and rolled back the working version.
To get the repro rolled back, we needed to set the current working branch. We did that by using:
git reset --hard k8ujbhy8lll999999
k8ujbhy8lll999999 with the commit that you want to go back to.)
If you run
, you can see where you are with the repro. Your working directory is clean:
$ git status # On branch master nothing to commit, working directory clean
Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time.