As modern web development methodologies continue to improve and optimize our workflows, one of the workflows that has risen to the top is a development deployment model using git.
Making it Secure
Before you do any of these steps, make sure you add the following to your .htaccess, and that URL Rewriting is working in your apache setup.
RewriteRule /?.git/ - [R=404,L]
RewriteRule /?.gitignore - [R=404,L]
Without doing this, anyone will have read-access to all of your code, and your entire source history.
This guide assumes a lot of knowledge about source control, management, and is not a guide to git. This guide assumes you can figure those parts out, but that you want to know more about one specific workflow that works very well in my opinion.
The main idea behind this workflow is that you will have a central repository, a development version of the software, and a published version of the software.
Convert something else to git
If you want to keep any history, the first step is going to be to convert the source control history to git. If you are using cvs, you will need to convert to SVN, and then to git. If you use SVN, simply use git to do a git svn clone of the repository somewhere on your local system. From there I recommend you move the .git folder to the remote production server, and make a copy in the development folder. If you go into each of these folders and type git status, you will see any differences that have not yet been committed to the repository, but you will be ready to make and receive changes.
Now that you are setup, time to develop
From there, things are relatively simple. Simply make any changes you want in your development environment. When you are finished with your changes, and they have been tested to your satisfaction, commit the changes, and push them to the repository. You can then enter your production server, and pull the changes from the repository. You can also simply pull directly from the development server, but organizations I have worked with tend to like a 3rd copy of the source, somewhere separated from the hosting environment.
If you want to, you can make emergency or urgent changes directly on the production, following any existing workflow you have for ensuring something is not broken. When these changes are complete to your satisfaction, simply commit and push them, and do a pull from the development environment.