Rapid deployment of small web applications on a server using git push
Context
Suppose we support a small web-project. We have a sandbox for development with git, debuggers and other useful things. The site is already running, and the code is copied from the sandbox to a remote server. The code sometimes has to (and possibly often) update and modify. Any changes naturally run in the sandbox. And then the question arises: how is it easy and convenient to update the code on the server?
The first solution that came to mind is a simple git push command: we push to a remote repository and get an updated version of the code on the server. But not everything is so simple.
In a fit of enthusiasm, we set up a repository on the server, carefully hiding the daddy .git from the web server. However, not everything is so simple: after the first change in the sandbox, the cherished git push server master returns us something like:
')
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 the non-bare repository, since the working tree will not correspond to the state of the branch”.
It should be noted that for bare-repositories such an error will not occur. But this type of repository is absolutely not suitable for our purposes.
Also, there will be no errors if we push not to the current branch. The result of this operation is further away from what we need.
Concept
To solve this problem, we will use the ability of git to respond to manipulations performed on the repository using hooks (triggers).
First, log in back to the server and create a production branch
git checkout -b production Edit the .git / hooks / post-receive file. 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 cause a merge of the master branch in production, which will actually update the files in the working directory.
Do not forget to set the permission to run the script:
chmod +x .git/hooks/post-receive We rejoice and return to the sandbox. Now you can update production with a simple git push server master command.
Pleasant additions
At the end of the .git / hooks / post-receive file, you can add a call to a script, the execution of which is necessary for the full deployment of the code. For example, clearing the cache, building the locale files, updating the database, etc ...
sources of inspiration
Source: https://habr.com/ru/post/151997/
All Articles