Well, this is a private site system, so I definitely don't want it hosted on
github or any other 3rd party server.  The other problem is that we meet
with the dev team mostly every day, so it would be a pain to constantly be
pulling updates from the main repo before the meetings.  It's a lot easier
for me to just have each dev push to the server and have that reflect the
latest changes.

Sorry, I'm very new to git, so I'm just trying to figure out the best
strategy to use.



-----Original Message-----
From: git-users@googlegroups.com [mailto:git-us...@googlegroups.com] On
Behalf Of Rick DeNatale
Sent: Friday, May 07, 2010 11:56 AM
To: git-users@googlegroups.com
Subject: Re: [git-users] Re: help - pushes not reflected on remote origin

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.

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

Reply via email to