Deploying to SiteGround via git push
Posted on October 20, 2014
Git push is the best thing for deployments since sliced bread. I don’t know if sliced bread was ever a deployment requirement, but trust me it’s good. I used to work at a company that used a similar stack (svn+rsync) to deploy. I’m glad to see many hosting companies getting on board with git-push. May you never have to use FTP again!
We have an account at SiteGround, which provides git push, but implemented in a different way than others like WPEngine. If you’re not careful with how you use it, it can lead to some strange results. I’d like to highlight some of the differences, so you don’t get yourself into trouble – especially if you don’t want core WP files to be under version control.
Navigating SiteGround’s cPanel
SiteGround uses the classic cPanel interface. To help you navigate, I’ve highlighted the areas of interest:
Creating a subdomain
If you haven’t done so yet, you may want to create a subdomain for your install. We use a single domain at SiteGround and put several WP installs using subdomains for testing purposes. Here’s what the subdomain configuration looks like:
If you’re setting up a WP install using your main domain name, you can skip creating a subdomain.
Creating your WordPress instance at SiteGround
When you go to add WordPress to your domain through cPanel, you’ll be using a tool called “Softaculous.” Click the big blue Install button to get started:
Select the domain (or subdomain) that you want to turn into a WP install.
Remember to change:
- Database name – it will be auto-generated, I tend to choose something that matches the domain or subdomain so it’s easy to remember what it goes with.
- Table Prefix – I use the normal
wp_– I think changing this has become “security through obscurity” and if you don’t keep your site up to date, this is unlikely to save you from an attack.
- Admin Username – replace the auto-generated username with something useful, but avoid admin since it is easily targeted by attackers
- Admin Email – replace the auto-generated one with a real email address for the site administrator.
When the installation is done, to exit Softaculous and get back to the regular cPanel, just click the My Accounts tab at the top and then click the red Go to cPanel button.
Creating the git repository at SiteGround
Click the SG-Git icon on from cPanel. You’ll be brought to a screen where all of your WordPress installations are displayed, and if they don’t have git repositories associated with them, you’ll be given the option to create one. When you click Create Git Repository for your WP install, a dialog will come up with some git information. Record the git clone command, we’ll use it later.
There will also be a SSH key and possibly the passphrase that goes along with it. Rather than using this key and sharing it with all the developers who you want to be able to push to this SiteGround account, I find it easier to add individual keys via cPanel.
Setting up SSH keys and config
SiteGround only takes DSA keys for SSH. If you don’t have an
id_dsa.pub file in your
~/.ssh directory, you can create one by opening a terminal and running:
ssh-keygen -t dsa
Once your DSA key is generated, you can add it to the SiteGround control panel by clicking the SSH/Shell Access icon in cPanel. Copy the contents of your
~/.ssh/id_dsa.pub file and paste it into the text area on SiteGround:
Some git clients won’t accept the fact that SiteGround uses a non-standard port for SSH. The way to get around this is to create a
~/.ssh/config file with an entry for SiteGround. If the
git clone command SiteGround supplied looks like:
git clone ssh://[email protected]:18765/home/sguser/public_html/git
~/.ssh/config file should contain:
Host mXX.siteground.biz HostName mXX.siteground.biz Port 18765 User sguser
Replace the Host, HostName, and User values with those from your account. I’ve changed them in this example for security purposes. To test you should be able to:
Notice you shouldn’t have to supply the username or the port, my
~/.ssh/config takes care of that. If you didn’t add a passphrase to your DSA key, you should be logged into SiteGround without having to supply a passphrase. Press Control-D to log out.
Now your git endpoint can be simplified for your git client (username and port are removed):
But don’t clone it just yet!
How not to push, and what will happen
The normal Git push workflow (for me) would be to init a git repository on my local system, add an origin of bitbucket.org or github.com and push it there, then add remotes (such as WPEngine production and staging) and proceed to push to those remotes. Instead I added SiteGround as a remote named
Origin vs. Endpoint
They key difference between SiteGround and WPEngine is that SiteGround treats their git repository as an origin (where you can pull and push), where WPEngine is a
--bare endpoint that you can only push to.
Since SiteGround is set up as an origin, if you just try to push there (without pulling or cloning from SiteGround first), you’ll likely get a warning like:
Updates were rejected because the remote contains work that you do not have locally.
Per git’s recommendation, you might then try to pull:
git pull sg-staging master
If your git repository was set up to not track WP core files, you’ll get a warning that:
error: The following untracked working tree files would be overwritten by merge: index.php license.txt readme.html wp-activate.php wp-admin/about.php ... Aborting
This is because the core WP files have been added to the SG-git repo, but not your local one. So then if your next move is:
git push sg-staging master --force
Several important files will be removed on your WP install at SiteGround: all of
wp-config.php, and all other PHP files in the webroot folder. Needless to say, your WordPress instance will no longer function without some serious repair.
Git push to SiteGround (modified functional workflow)
Since SiteGround sets up the git repository as an origin, it is better to start your WP project with a
git clone from SiteGround, but before doing that, I wanted to clean things up…
If you don’t want core WP files under version control, the easiest solution is to remove them from version control directly at SiteGround before cloning the repo.
Since we’ve already got SSH working, from your terminal you can:
ssh mXX.siteground.biz cd /home/sguser/public_html/git git rm --cached -r wp-admin/ wp-includes/ *.php *.txt *.html git commit -a -m "Removed WP-Core files"
Again, replace the host (
ssh line) and path (
cd line) with the values from your
git clone command supplied by SiteGround. The ones used here are examples. The
git rm --cached command removes the core WP files from revision control, but leaves them on the filesystem, so your installation doesn’t go into a state of disrepair (like above).
Once that is done, you can clone!
git clone ssh://mXX.siteground.biz/home/sguser/public_html/git
SiteGround will be the
origin, so let’s edit that (usually bitbucket.org or github.com is the true origin). This will rename it to
git remote rename origin sg-remote
Now when you want to push to SiteGround, just do:
git push sg-remote master
If you try to push a different branch to SiteGround, the branch will be transferred, but the code won’t be switched to that branch. To get around this you can overwrite SiteGround master by doing:
git push sg-remote my-branch:master
Hopefully this gives you some insight into how the SiteGround git deployments work, so you can use them effectively.
If you’re interesting in learning more about git deployments or how to set up your own git-push-to-deploy, I recommend starting with this article to familiarize yourself with a basic setup:
8 CommentsLeave Comment
I was working with Siteground git recently also. I ended up doing everything locally and pushing to SiteGround with a command like. `$ git remote add sg-remote ssh://[email protected]:18765/home/USERNAME/public_html/staging` `$ git push sg-remote develop` I used the skeleton model from Mark Jaquith with having WordPress as submodule. This will work on every plan of SiteGround and not just the top tier where you have the interface. I have not yet used interface yet so I am not sure of the pros. FYI - The code cut off on the a mobile screen so I had to open the site on a larger screen to see the code comments.
Something must have changed recently at SiteGround because when we started using it (earlier in 2014), I don't remember having to do anything special when pushing there initially. Most recently I've ran into the issues highlighted in the post, so I thought I'd write it up for anyone experiencing the same thing. I believe someone from SiteGround support has seen it, so maybe things will change for the better (easier).
Hey Justin, I'm Nikolay and am the CTO @ SiteGround.com. I've noticed this blog post, which provides a really good explanation and guidelines on how to use our tools and am very thankful for that. I've decided, however, that I need to add some more info on how our git integration works and a better way to use it with your flow. Hence, I'm writing this comment. Indeed our integration could be different from the one of WPEngine, but in general it is not something fundamental and it is all about the user habits and how he or she prefer to use Git. As you've mentioned, when creating a git repo with our tool it adds all the installation files to the repo, except some excludes as shown on your screenshot. But still you can add a custom ignore list by creating a .gitignore file within the WordPress installation folder. Furthermore, you don't have to clone the repo but only add it as a remote. After that you simply need to merge it to your master branch by using pull. So, here is what I would have done if I was using your flow: 1. Create SiteGround Git repo with the cPanel tool 2. Create a .gitignore file within the folder of the WordPress installation the repo was created for and add the following to it: wp-admin/ wp-includes/ *.php *.txt *.html 3. Go to the local repo and add a new remote one: git remote add sg-remote mXX.siteground.biz:/home/sguser/public_html/git 4. Merge it to the master branch: git pull sg-remote master 5. Now it is safe to push: git push sg-remote master This will not erase or affect any of the core WordPress files because they are already in the git ignore file. However, those steps are specific to your flow. Developers use various of flows to accomplish the same tasks and it only depends on their preferences and habits. This probably worked for you with WP Engine without to have to do anything special, because I assume they exclude the WordPress core files by default in the git repo, which is not the case with our setup. We've decided to give full freedom to the developer and leave it up to him to decide how to control and configure his repos, which btw is no completely possible with WP Engine.
Thank you Nikolay, I'll highlight your comment!
What is the purpose of pushing files to your Wordpress site? currently I use the WP tools for managing pages, posts, themes, plug-ins, user, etc. What functionality does creating a WP repo add?
Excellent post - thank you for the details and workarounds. Much appreciated! Justin and Nikola, this is very helpful!
Your excellent post got me started digging deeper into this topic. I think there is an even easier method of deploying to siteground. Here is a link to the tutorial https://github.com/delcon/siteground_git_deploy
This was such a great and useful post. Big thanks goes to both Justin and Nikolay