Deploy small web applications quickly on the server with git push

Context

Suppose we support a small web project. We have a development sandbox with git, debuggers, and other useful things. The site is already running, and the code is copied from the sandbox to the remote server. The code has sometimes (and possibly often) to update and modify. Any changes naturally run in the sandbox. And here the question arises: how is it possible to update the code on the server as simply and conveniently as possible?

The first solution that comes to mind is a simple git push command : we push into the remote repository and get an updated version of the code on the server. But not so simple.


In a fit of enthusiasm, we configure the repository on the server, carefully hide the .git folder from the web server. However, not everything is so simple: after the first change in the sandbox, the covetedgit push server master will return something like this to us:

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.

The general meaning of this message is: “you cannot push into the current branch of a non-bare repository, since the working tree will not correspond to the state of the branch”.

It is worth noting that for bare-repositories such an error will not occur. But this type of repository is completely unsuitable for our purposes.

Also, there will be no errors if we push not to the current branch. The result of this operation is even further from what we need.

Concept

To solve the problem, we will take advantage of git's ability to respond to manipulations performed on the repository through hooks (triggers).

To get started, log in back to the server and create a production branch

git checkout -b production

Edit the file .git / hooks / post-receive . The content should be like this:

#!/bin/sh
cd ..
env -i git merge --ff-only master

This setting allows you to leave the remote repository with the current production branch. And each push to this repository will call the merge of the master branch in production, which will actually update the files in the working directory.

Do not forget to set permission to run the script:

chmod +x .git/hooks/post-receive

Rejoice and go back to the sandbox. Now you can update production with a simple git push server master command .

Nice additions

At the end of the .git / hooks / post-receive file, you can add a script call, the execution of which is necessary for the full deployment of the code. For example, clearing the cache, assembling locale files, updating the database, etc ...

sources of inspiration

• Git Tip: Auto update working tree via post-receive hook
• how do I fix such a non-bare push?