On Fri, May 7, 2010 at 11:31 AM, Matt Palermo <mpale...@vt.edu> wrote: > Okay, maybe someone can give me advice for the best way to accomplish > this... I have a team of developers (myself included) for a PHP website. I > also have a design team. On the main webserver I want to setup the "live" > site where all tested code will go. Then for each developer on the team, I > want to have another site on the server where that developer can work and we > can all see his development in progress. The design team will also have > their own site on the server. So it would be something like this: > > - Server > http://site.com/live (live site with only tested/approved code) > http://site.com/dev1 (test site for developer 1, which is a clone > of the live site) > http://site.com/dev2 (test site for developer 2, which is a clone > of the live site) > http://site.com/design (test site for design team, which is a clone > of the live site) > > So the way I've tried to implement it is this... Setup a main "bare" repo. > Then have clones of the main repo for "live", "dev1", "dev2", "design" all > in their respective webroot folders. Then let's say dev1 makes a change > that is tested and ready to go live... I will go to the server into the > dev1 repo and push it to the main repo. Then I will go to the "live" repo > and pull the changes to it. > > All devs will be able to clone their server "dev" repo to their local > machine and work from there. However, I want their server "dev" repo to be > as current as possible so that I can go to the server site for them and see > the latest changes. So if developer 1 makes changes on his local clone, > then he will commit the changes and "push" them to the server dev repo so > that the entire team can view the changes on the server site. The problem > I'm running into is that when the dev pushes commits to the server, the > server dev repo working files/folders don't reflect the changes that were > pushed to it. Therefore I can visit the "dev1" site after a commit was > pushed to it and it will look/work the same as before the push. I need to > always keep the "dev" sites current with the latest changes. > > Should I be doing something different in my workflow? Does anyone have any > advice on setting up a system to work this way? > > Thanks, > > Matt
Why are you pushing from the server(s). I'd set up a main git repository somewhere, probably on github. Have the developers clone this and push changes, use branches to control production vs. staging. Then to deploy to a server have it checkout a specific branch and pull. I don't know about php apps, but this is the way things are normally done with Rails. Most Rails developers use a tool named capistrano to deploy, which has recipes for fetching code from git, rolling back changes... There's probably something similar for php apps. As a matter of fact it appears that some folks are using capistrano for php deployment http://www.google.com/search?q=capistrano+deploy+php Having a separate staging server for each developer seems to be overkill to me, most of the projects I've worked on have the developers run code on their own development machines, and one staging server where code not ready for production can be deployed for manual acceptance testing, or review or ... But I guess there's no reason why you couldn't do that. HTH -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.