Get Git to manage a website?

Hey SP,

I’m curious about using git to manage updates of a website.

First, let me explain my situation. I’ll be as “quick to the point” as possible.

I am the main coder of a website, I work with one web designer once in a while. Our website is currently divided up into 4 subdomains, each with their own mysql databases.

  1. www. is the live public access site
  2. dev. is where I write new code and features
  3. design. is where the designer writes new css or images
  4. live-test. is where we test out our updates

I have written a small collection of web based tools in PHP that allow me to compare the differences between the subdomains. This helps me see what files are new or updated in comparison to the other subdomains. These tools also allow me to quickly put new files, or new versions of files on the other domains, or completely mirror one subdomain to the other. These updates tools also allow me to quickly mirror one database from one subdomain to the other.

My tools no longer work because they make extensive use of the exec() function in PHP. The exec() function allows an executing PHP script to run a native linux program and then receive the output from the command. We have just switch server hosts, and our new host will not permit us to use exec() due to security concerns.

So that’s why we are now considering git to manage the update process. Can git provide me the same functionality as my web based tools and how would I even begin to set this up?.

Here is what I’m thinking I’d have to do to set this up. Please correct me if I’m wrong.

  1. Install git on my machine
  2. Install mysql and apache + php on my machine
  3. Download our website and database onto my computer.
  4. Turn the webroot and sqlroot into git repositories
  5. Install git on the webserver
  6. Get webserver to checkout the website and database from my machine.
  7. Get designer to install git on his Mac and get him to checkout the site

Now for updating the website, it would go something like this.

  1. The designer would commit his changes to my machine.
  2. I checkout the new latest version with his changes.
  3. I make my changes to the website, and commit them.
  4. Get webserver to check out new version of the website.

To me this all seems a bit cumbersome for just managing a website so I’m confident I must understand the process incorrectly. I’m also curious how git would manage different databases and how it could compare the differences. Also curious what happens if I and the designer each work on the same file and both have valid changes that need to be committed. I’m assuming we can only alter one file at a time.

I know this thread is getting long! So I’ll wrap it up here and say thank you kindly for reading through and hopefully responding.


  1. www. is the live public access site
  1. dev. is where I write new code and features
  2. design. is where the designer writes new css or images
  3. live-test. is where we test out our updates

4 separate environments seems a bit much for a 2 man team.

Two environments on the server should be enough - www(production) and live-test(staging), you and your designer should be working in your own local environment and making all changes there. I can’t think of a legitimate reason for the other two environments on the server.

So you’ll want 3 remotes that you can push/pull code from
origin - a central repository like Github
staging - staging server
prod - live server

At a minimum you want two separate branches in git:
develop - where you and the designer make changes
master - production ready code

  1. Turn the webroot and sqlroot into git repositories. I’m also curious how git would manage different databases and how it could compare the differences

Not all files on the server need to be in source control, only what you want to be able to change. I’m not sure what you have in sqlroot but assuming it’s your data in your database this shouldn’t be in source control - git isn’t used to compare differences in databases. What should be in source control instead are sql scripts for updating your database, schema changes, new data - that type of thing.

The basic work flow goes something like:

You and the design both checkout from origin/develop to get the latest from the central source repo.
Make your changes
Commit your changes
Push to origin/develop

You and the designer can both work in the same branch are in sync, when you’re confident enough with the code there you can merge to master and push to the staging server to test. If all goes well you push master to the production server and run any necessary database scripts.

If you try to push to origin/develop and your designer has also made changes to the same files you’ll get a merge conflict and be able to see both sets of changes along-side each other. It’s up to the person who pulls the code last to resolve these conflicts and commit the final versions. This all happens before the code is commited and pushed to a server.

I hope that gives you a bit more info, I think git will make things a heck of a lot easier for you than comparing differences in code and databases across your four servers :slight_smile:

1 Like