Home/ Questions/Q 1102003
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T01:07:00+00:00

Edited: (after seeing Luke’s answer) I’m looking to develop a website and all the

  • 0

Edited: (after seeing Luke’s answer)

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 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’

Thanks for taking the time to read this VERY long post 🙂

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’m only going to address questions 1 – 3 (and briefly 5). Firstly, I don’t think you should have your canonical repository hosted on your production server.

    Since you don’t want to set it up locally, I’d suggest you create the repository somewhere on your server other than public_html, push it out to GitHub (or your choice of Git hosting), then git clone it in public_html, etc.

    Further, I would use master as the production branch, creating feature branches for development, then merging them into staging to test before pushing to master after testing on staging.

    To recap:

    public_html – master branch checked out – just do a git pull to update
    staging – staging branch checked out
    dev – whatever feature branches you are working on, etc

    This is just one git branching strategy, but it’s one that my team has used successfully.

    As for 3, you’ll want to setup Hudson so that it pulls the latest changes on staging automatically. See What's the workflow of Continuous Integration With Hudson? or look at the sidebar to the right to figure out how to get that working. The point of CI is that it needs to be automated, otherwise it’s not CI 🙂

    Finally, an easy way to limit access to a site is using an .htacess file (assuming your host uses Apache, which they seem to). See http://httpd.apache.org/docs/2.2/howto/htaccess.html or Google .htaccess.

    • 0