Question

It is definitely time for me to learn about source control, and git in particular.

I do a lot of web development and most of the time I do a lot of development work on the live production server. I know this is really bad.

I just haven’t quite got my head around how local development and then deploying to a live site with git works.

Is the following how it might work out:

1. Set up an environment on my local machine that is as close to my web server as possible

2. Create a git folder where I will develop my project (or download the existing project from the live server).

3. When I’m ready to push my changes commit them in git.

What I’m not sure about is the following:

• How to push my changes out to the live server?
• What if I accidentally delete my local copy?
• What about my database? If I add new tables and data on my local machine will I need to manually make these changes on my live server too?

---

EDIT

Yes, sorry, not enough detail.

I do all my coding in Coda for Mac, I have a few different projects on the go, but most of these are PHP/YII running on Apache. Database of choice is MySQL.

PHP is going out raw.

Answer 1

If your web site doesn’t require compilation, you might just choose to deploy it directly from the Git repository.

• Do your development on your local box, as you usually would.
• Check your code into Github or another site like it frequently
• Since you don’t need to compile your site, your Git copy is ALMOST ready-to-go
• You either want to exclude .git directories from APACHE service, or
  remove them after “git clone”

Your database is another issue. You will probably:

• Write scripts to make changes to your database rather than making them in a UI
• Include a version stamp somewhere (maybe in the database) identifying the current schema
• Name your scripts with database version numbers (I also keep an indicator of the associated code revision that is required for compatability – I automatically stamp it with Git changeset ID)
• In order, run all the scripts greater than the current database revision (but not greater than the current software revision. I scripted out this process too)

You do all this in bits and pieces on your development machine as though you were doing it in production. When it’s time-to-go, you still really probably want test:

• mark your revision with a friendly branch name, like Release23a or whatever you choose, so you can find it later
• replicate your production database to a test environment (live data issues that can block upgrades partway through are a PAIN)
• deploy the whole package to a test environment, running MySQL scripts and doing your Git export (using your new branch name)

Then, you’ll probably continue working and checking into Git as usual. Often, you’ll be in the middle of implementing an ugly bit of code and need a quick patch to your live site. But you don’t want to just go hack code into your live site. Instead:

• Check out your Release23a
• Make your hotfix
• Check it in as usual (it will save to the Release23a branch)
• Tag it again, Release23b
• Deploy as before (Release23b)
• Merge Release23b back into your main codeline

A quick note about branching. You can always go back and get ANY version you checked in by date/time, but it’s easier to find them by name. Additionally, once you branch, you can do work on that branch, and then check it in again. Now you have a bifurcation in your codelines. You are making changes to yesterday’s hotness, and it isn’t automatically getting applied to today’s hotness. If you WANT that, you have to manually merge it. Merging is the process of saying “Git client, please try to automatically apply all the code edits from the Release23a/Release23b delta to my latest hotness”.

As you can see, you have some very cool tools available with Git. Deleting your local code isn’t an issue, assuming you’ve been good and checking in frequently.

Note that Git has the concept of local commits. Those don’t save your work from a hard-drive crash until you sync.