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


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  
        git push origin
        cd ../public_html
        git checkout -f  (live site should have the latest dev from ticket#)
    revert the merge: git checkout master~1; git commit -m "reverting ticket#"
    update ticket# that testing failed with the failure details


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'
  • Personally I would just use branches for each. git branch staging;git branch dev and then have each checked-out branch be different.
    – Kzqai
    Jun 29, 2011 at 16:06

1 Answer 1

  1. Yes, the workflow makes sense. The only thing I don’t quite get is the need for a separate testing platform. I mean yeah, it’s useful if you have a testing team to give them their own platform, but if it's just you? Not so much. IMHO, for small-scale development teams, this sort of thing is unnecessary and becomes a hassle.

  2. I’m going to suggest the obvious here (and I’m ready to be shot down), but what about git-revert?

  • I wanted to have a separate testing platform so I could have a standardized location to run all my hudson tests. I haven't looked into hudson yet but I figured it would be make things easier to have a central location.
    – user2022
    Sep 21, 2010 at 18:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.