I'm looking to develop a website and all the work will be done remotely (no local dev server). The reason for this is that my shared hosting company a2hosting has a specific configuration (symfony,mysql,git) that I don't want to spend time duplicating when I can just ssh and develop remotely or through netbeans remote editing features.

My question is how can I use git to separate my site into three areas: live, staging and dev.

Here's my initial thought:

• public_html (live site and git repo)
• testing: a mirror of the site used for visual tests (full git repo)
• dev/ticket# : git branches of public_html used for features and bug fixes (full git repo)

Version Control with git:

Initial setup:

cd public_html  
git init  
git add *  
git commit -m ‘initial commit of the site’  
cd ..  
git clone public_html testing  
mkdir dev

Development:

cd /dev
git clone ../testing ticket#
all work is done in ./dev/ticket#, 
then visit www.domain.com/dev/ticket# to visually test
make granular commits as necessary until dev is done
git push origin master:ticket#  
if the above fails:
    merge latest testing state into current dev work: git merge origin/master
    then try the push again
mark ticket# as ready for integration

integration and deployment process:

cd ../../testing
git merge ticket#  -m "integration test for ticket# --no-ff (check for conflicts )
run hudson tests

visit www.domain.com/testing for visual test  

if all tests pass:  
    if this ticket marks the end of a big dev sprint:  
        make a snapshot with git tag  
        git push --tags origin  
    else  
        git push origin
        cd ../public_html
        git checkout -f  (live site should have the latest dev from ticket#)
else:
    revert the merge: git checkout master~1; git commit -m "reverting ticket#"
    update ticket# that testing failed with the failure details

Snapshots:

Each major deployment sprint should have a standard name and should be tracked.

• Method: git tag
• Naming convention: TBD

Reverting site to previous state

If something goes wrong, then revert to previous snapshot and debug the issue in dev with a new ticket#. Once the bug is fixed, follow the deployment process again.

My questions:

1. Does this workflow make sense, if not, any recommendations
2. Is my approach for reverting correct or is there a better way to say 'revert to before x commit'