Git is available on our platform and all new sites deployed at Seravo have git initialized by default. Using git for version control greatly improves the productivity of programmers, decreases the number of mistakes made, provides an audit log of code changes and helps to verify that the code on the site does not have any unwanted changes.
You can simply clone the remote git repository to your machine and start working. All new sites deployed at Seravo have git initialized by default, so one can directly run
git pull and
git push commands against it.
$ git clone ssh://$SSH_USER@$SITE.seravo.com:$SSH_PORT/data/wordpress ~/Projects/$SITE --origin production $ cd $SITE
A fresh new WordPress site at Seravo has the git history from our WordPress project template. This is a good starting point, as it is easier to later merge updated versions of our project template to your project.
Note: Do not do this if you have existing site in production. Pushing to production site will overwrite your current content, and might lead to data loss.
If you don’t want to use the Seravo project template as a starting point for your repository, you can also use your own WordPress project template for a new site and simply force push it to the newly created site, so that the git history is overwritten with your own custom project template history and contents.
$ git clone https://github.com/<customer>/wordpress-project ~/Projects/$SITE $ cd ~/Projects/$SITE $ git remote add production ssh://$SSH_USER@$SITE.seravo.com:[$SSH_PORT]/data/wordpress $ git push --force production master
$ git remote add github firstname.lastname@example.org:ottok/example-site.git $ git remote -v github email@example.com:ottok/example-site.git (fetch) github firstname.lastname@example.org:ottok/example-site.git (push) production ssh://email@example.com:12345/data/wordpress (fetch) production ssh://firstname.lastname@example.org:12345/data/wordpress (fetch) upstream https://github.com/Seravo/wordpress (fetch) upstream https://github.com/Seravo/wordpress (push)
Once you have the project on your own machine, starting it using Vagrant is as easy as running
# Start vagrant and follow the questions from the installer # It's safe to just push enter to all of them $ vagrant up # You can connect into vagrant $ vagrant ssh # You can pull the production database (not required on new sites) $ wp-pull-production-db # You can also pull the production plugins (not required on new sites) $ wp-pull-production-plugins
Now you can open http://wordpress.local/ in a browser and edit the files in you project and see the result immediately.
When you think your code is good to go, commit it and push to production with:
$ git push production master
.git/hooks/post-receive will run on the receiving end and run Composer and Gulp if configured to do so. Note that if you created the git repository yourself, there will be no post-receive hook until you have installed it from
When you are done, you can shut down Vagrant with
halt. If you completely want to destroy the virtual image (for example to save disk space) execute
destroy. Note that even after
destroy you will have files under .vagrant and all the Composer installed modules etc under your project. Use
git clean to get rid of all traces of
$ vagrant halt $ vagrant destroy $ git clean -fdx && git reset --hard
To provide a seamless
vagrant up experience for anybody who starts to develop the site using the git repository as their sole starting point, you should include a file named
vagrant-base.sql in the repository that contains a suitable minimal database with some example settings and contents.
You can easily create such a database dump file by running inside Vagrant the commands
$ cd /data/wordpress $ wp db export vagrant-base.sql --path=/data/wordpress/htdocs/wordpress --skip-extended-insert --allow-root --single-transaction
If Vagrant detects that a file named
vagrant-up-customizer.sh is present, it will automatically be run every time
vagrant up is invoked.
By default Git does not accept pushes on a non-bare repository and emits this warning:
laptop$ git push production Counting objects: 8, done. Delta compression using up to 8 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 667 bytes | 667.00 KiB/s, done. Total 8 (delta 7), reused 0 (delta 0) 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: is denied, because it will make the index and work tree inconsistent remote: with what you pushed, and will require 'git reset --hard' to match remote: the work tree to HEAD. remote: remote: You can set the 'receive.denyCurrentBranch' configuration variable remote: to 'ignore' or 'warn' in the remote repository to allow pushing into remote: its current branch; however, this is not recommended unless you remote: arranged to update its work tree to match what you pushed in some remote: other way. remote: remote: To squelch this message and still keep the default behaviour, set remote: 'receive.denyCurrentBranch' configuration variable to 'refuse'. To production:/data/wordpress ! [remote rejected] master -> master (branch is currently checked out)
laptop$ ssh production production$ cd /data/wordpress production:/data/wordpress$ git config receive.denyCurrentBranch updateInstead
If you want, you can remove the whole git repository simply by running:
$ rm -rf /data/wordpress/.git
This is however not recommended. Using git for version control greatly improves the productivity of programmers, decreases the number of mistakes made, provides an audit log of code changes and helps to verify that the code on the site does not have any unwanted changes.
Seravo’s WordPress upkeep includes 24/7 monitoring. If a site goes down, Seravo will check what is wrong and attempt to recover the site. Details depend on what was the root cause of the failure. While coding work is not included in our fixed monthly fees, in some cases Seravo’s staff might still do some small code changes if that is urgently needed to restore the site back in operation. If Seravo makes such changes and the site is using git for version control, Seravo will commit the changes to git.