I use SiteGround for most of my personal websites. I love it because I can create unlimited sites without any additional cost.
I prefer to use git to deploy code rather than SFTP. I make my changes locally, and when I’m happy with it I push them with git push production master.
SiteGround has git support built-in, but it works a bit differently than other hosts with git push. This article by 9seeds provided a lot of guidance here.
Add a .gitignore file
By default, SiteGround will version control the entire wp-content directory: your themes, plugins, and uploads. If you prefer to only include certain themes and plugins (like I do), you’ll first want to add a .gitignore file before creating the git repository in SiteGround.
I had migrated a site to SiteGround, then clicked “Create git repository”. The repo was massive because it included 2GB of uploads. Adding the .gitignore afterwards and deleting the uploads directory wouldn’t help because the uploads are still part of the history of the repo. I fixed it by deleting the repo, adding the .gitignore file, and creating a new repo.
Here’s my sample .gitignore file. Edit it to include any themes and plugins you’d like to version control, then upload to the top level of your WordPress site.
Create the repo on SiteGround
Log into SiteGround and open cPanel. Click on the “SG-Git” tool (use the search on the left to find it).
At the bottom you’ll see a list of domains that are not currently version controlled. Click the green “Create git repository” button next to the site you want.
You’ll then see a popup window containing a “git clone” command and an ssh key. You’ll only need the git clone command for what we’re doing.
Copy the git clone command and run it locally wherever you want the site to be. For instance, I have a /wpdev directory on my computer where I have most of my sites, so within that I run the git clone command. It will create a new directory using your domain name (ex: /wpdev/yoursite.com). You can rename it if you like: mv yoursite.com yoursite
Integrating GitHub
Your new local repository will have a remote named origin pointing to SiteGround. I prefer having origin point to GitHub and production point to the live site. To change this:
- Rename the remote:
git remote rename origin production - Create a private repo on GitHub. Click “Clone or download” and copy the URL given (screenshot).
- Add the remote origin:
git remote add origin {url here}
Private GitHub repos are only available for paid accounts ($7/month). Alternatively, you could use the same approach with BitBucket which offers unlimited private repos for free.
Making code changes
When you’re ready to push them to GitHub, run: git push origin master. When you’re ready to deploy your code changes to your website at SiteGround, run: git push production master. I also like to use WP Migrate DB Pro for pushing and pulling the database.
That’s it! It’s pretty simple to setup and a lot simpler than SFTP for deploying code changes. Let me know if you have any questions or additional SiteGround tips.
Andrew says
Bill, Thanks so much for this. One question. Would this work if I used Siteground to create an additional environment? So for example, pushing from various developers locals to a development environment to test, and then to the live environment. How would the push from dev to live work?
Bill Erickson says
I haven’t tried it but yes, I think that would work just fine. You would create two installs – dev.yoursite.com = the
developmentremote, and http://www.yoursite.com = theproductionremote.As you’re developing, push changes to
origin(GitHub) anddevelopmentfor review by the team. Once it’s all approved, push code toproduction.Jacob says
I am also trying to figure out how this works, specifically with Siteground’s staging site feature. Through cPanel you can click a button to make the staging version live. I’m not sure exactly what happens behind the scenes there how that would work with a git repo for the staging site. Would I need two repos? One for staging site, one for live site?
Bill Erickson says
I haven’t used the staging feature in SiteGround, but I would create a single repo and have two remotes (
stagingandproduction).To send code to the staging environment, run
git push staging masterTo push code changes to the development environment, run
git push production master.You might not need to run the production code push if SiteGround’s “Staging to Production” feature copies all code over.
Jose M. Villar says
Very good tutorial, too bad is only applicable for GoGeek accounts as the other two service tiers do not include git functionality.
Serhan says
Bill, thank you very much, this is a very useful and much-needed article.
May I ask, one tiny detail, within this workflow how you manage the local installation? Assuming that we’re using Desktopserver let’s say, do we first make a local WP installation into /wpdev/yourwebsite.com/ ?
Due to .gitignore configuration, we will only clone two folders: the chosen theme and plugin folder; so I’m guessing that we need to solve the core WP installation somehow somewhere, we can’t clone core WP files from Siteground, as the database or .htaccess are all different (maybe we are solving DB with WP Migrate DB Pro) yet WP versions might be different on the production Siteground and in your local installation.
Bill Erickson says
Here’s a description of my development workflow.
Yes, you would create a new WP installation locally. We’re only keeping our custom theme and CF plugin version controlled, which simplifies the management of multiple installs. You could have different plugins installed on both, different database credentials in wp-config.php… because none of that is version controlled.
I do use WP Migrate DB Pro to push/pull the database, but it works the same with any other approach (db dump from phpMyAdmin,
wp db exportwith wp cli…).Ian says
Bill,
I’ve have been trying this resolve this exact same issue. I’m going to give your solution a go tomorrow, thanks again.
Jason says
Hi Bill,
Thanks for your article – this almost works for me. Perhaps its the difference in accounts, but if I go to create a repo using their SG GIT Tool (on my SiteGround Cloud VPS account) the pop-up window you describe containing GIT Clone & an SSH Key is non existent – it just straight away starts creating the repo.
Out of interest, I take it you just dropped your .gitignore file in the WP site’s root directory?
I have a support ticket in with SG now, & with Bitbucket to try & get my process all sorted.
If I get anything good, I’ll post it here.
I’m only wanting to track custom plugin & theme code too – nothing else.
Bill Erickson says
Correct, I dropped the .gitignore file in the WP site’s root before using their SG Git tool.
Please share whatever you find out from their support.
Thanks
carter says
How are you able to clone without SSH access? You have no connection to the server?
Bill Erickson says
I’m sorry if it wasn’t clear. Yes, you must have SSH enabled on your account. This is available on the GoGeek plan.
Rob says
Siteground has an old version of git installed (2.6.0 from 2015) which means some things may not work as expected.
silverdarling says
Thanks for article.
My understanding is SG Git does not sync the WP database (you use a plug in to move db).
Is there a git tool or WP plugin that syncs and merges the WP database? I have a local version of database where I’m adding settings for e.g. custom fields (common for CMSs, the databse stores options and settings not just content) and remote version where client is adding content.
I want to merge my settings with client’s content, not overwrite their content by simply replacing db. Anyone know a way to do this?
Bill Erickson says
Version control only applies to files, not databases. There are many reasons for this:
– The database isn’t a file sitting on your server, so pushing up a new .sql file to the server wouldn’t update the database
– The production database is always changing, so any time you pushed code up you’d lose recent content on your production site.
– Your database can store private, confidential information which you don’t want permanently accessible in a repository.
Merging databases is an incredibly difficult problem to solve. Delicious Brains (the company behind WP Migrate DB Pro) tried to build a product for this called MergeBot but after a year they shut it down (more information).
When you say you’re “adding settings for e.g. custom fields”, does that mean you’re creating new metaboxes or entering data into existing metaboxes? If the latter, you might try version control for ACF metaboxes. Any time the settings for a metabox are changed (ex: adding new fields, creating a new metabox), ACF generates a JSON file which can be version controlled and deployed to other servers.
Steve says
Hi Bill,
Excellent article, thanks for the initial idea. I’m using SG and have created a git repo for the entire WordPress with some ignored files (blogs.dir and uploads etc). It clones ok, but when I come to push my changes I’m getting an error stating that it refuses to update the master…
remote: error: refusing to update checked out branch: refs/heads/master
Have you set the ‘receive.denyCurrentBranch’ configuration variable to ignore to get this to work? Is it safe to do that? Or have I misunderstood something in all that?
Thanks for your help in advance 🙂
Steve
Bill Erickson says
It’s been a while since I did this so I don’t remember all the details, but I do know that I didn’t set any configuration variables.
You might try reaching out to SiteGround support. They can probably help you troubleshoot the issue.
Stuart says
I’m having this same problem. I opened up a ticket w/ Siteground support but haven’t heard back yet. Any updates?
Chris says
Hi Bill – this article helped a lot, but after I do a git push I’m not seeing the changed files in the “File Manager” in Site Tools, nor are the new theme files showing up in WordPress. Is there an additional step required after you do a git push? I thought maybe they’d have a hook setup for it that would automatically checkout any changed/new files but that doesn’t seem to be happening.
To Steve and Stuart – I get this same error message every time I create a new repo. I have to SSH into the site and run this command `git config receive.denyCurrentBranch ignore` before I can push into the repo. That may help?
Thanks,
Chris