On May 7, 7:31 pm, "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:
> - Serverhttp://site.com/live (live site with only tested/approved
> code)http://site.com/dev1 (test site for developer 1, which is a
> 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.
While Rick's suggestion sounds more sensible, your proposed workflow
involving pushing to non-bare (devN) repos can actually be done using
hooks -- you just missed the last bits of that FAQ entry. A working
sample of such hook can be found in  for instance (also don't miss
the article it refers to).
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
For more options, visit this group at