3

I have a bare git repository set up on a production server, and it uses a post receive hook to deploy whatever I push there:

#!/bin/sh
GIT_WORK_TREE=/path/to/webroot git checkout -f

To deploy I do

git push production

From my work station, and everything is taken care of. But say I push a commit that breaks something and I want to revert asap. Will doing the following work:

git push production [id of commit to revert to]:master

IE will this still deploy everything in to the webroot correctly?

Cameron Ball
  • 4,048
  • 6
  • 25
  • 34

1 Answers1

4

That should work as expected. You probably need to do git push +<commit>:master (note the +) in order to replace the bad commit at the HEAD of production master.

+<commit>:master is a refspec, see the git push manpage for more information about refspecs.

I would recommend reverting more explicitly without needing to force push to the production server by doing:

git revert <commit to revert>
git push production

or

git reset --hard <commit to revert to>
git push -f production

See How to revert Git repository to a previous commit?

Community
  • 1
  • 1
mwhite
  • 2,041
  • 1
  • 16
  • 21
  • If that's the case, then what does this do: git push production [id of commit to revert to]:master – Cameron Ball Feb 14 '14 at 05:52
  • Sorry, didn't know what I was talking about. – mwhite Feb 14 '14 at 06:06
  • I just tested with a similar setup: a "staging" repository from which we push upstream to a bare "production" repository with a post-receive hook that updates files to a working directory. running `git push +:master` worked great as a rollback command, leaving my staging directory at the most recent commit so I can work on fixing whatever problem made me need to rollback the deployment. Thanks! – ryanrain Sep 09 '18 at 17:24
  • This works perfect. Then, when you want to deploy to the latest commit of the master branch, just run `git push production master` (which is the same as `git push production +HEAD:master`) – Quinn Comendant Jun 08 '19 at 02:07