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.
