Deploying from Git when the site is one of many

Deploying by dragging files works until the day you cannot remember which version is live on which site. On a network that day arrives early: two sites share a theme, one got a fix, the other did not, and nothing on the server records what happened.

A repository on the account fixes the record. What is live is whatever was last deployed from a known commit, and you can see which commit that was.

Set it up on the account

The panel asks for two things: a name, and somewhere to put it. Choose a path in the home directory rather than anywhere under the site, and if the project already exists elsewhere, point the clone option at it instead of starting empty. The video above runs through the form.

What you get back is an address to push to. Nothing new has to be handed out for it, because pushing rides on the key you already authorised for shell access.

Never check out into the web root

A repository checked out directly into public_html puts a .git folder under a public URL. That folder contains your history, including files you committed once and deleted later. Configuration files with database passwords are the classic case, and removing them from the working tree does not remove them from history.

Keep the repository elsewhere in the home directory and copy the built files out at deploy time.

What deploys and what does not

A push updates the repository; it does not update the site. The copy happens when a deployment file at the repository root says what to move where. Two things are worth deciding before you write it:

• Copy only what your build produces. A task that mirrors a whole directory will happily erase an uploads folder the site writes to.
• The database is not included. Git moves files. Content, settings and anything else living in MySQL stays where it is, which is usually what you want for a code deploy and never what you want for a migration.

Where it pays off on an estate

The value is not one site, it is the second and third. A shared theme lives in one repository and is deployed to each account that uses it, so "did this site get the fix" becomes a question with an answer rather than a guess.

It also makes rollback real. When a deploy breaks a site, you deploy the previous commit instead of trying to remember which files you changed.

What it does not replace

Git is not a backup. It holds your code, not your uploads, not your database, and not the state of the account. A repository and a backup answer different questions, and the day you need one is not the day to discover you only had the other. Keep what your backups actually cover clear in your head separately.