[RndTbl] Revision control

[Sean Walberg]

On Wed, Nov 2, 2011 at 2:23 PM, Trevor Cordes <trevor at tecnopolis.ca> wrote:

> Here's the copies I currently have that I'd like to git-itize:
>
> 1. Raw dev copy on my box
> 2. Testing copy on production server
> 3. Live copy on production server
> 4. 2nd dev copy on some other guy's server
> 5. git "master" copy somewhere on production server
>

You'll want to set up what's called a "bare repo" somewhere. A bare repo is
basically the contents of the .git directory with none of the working
files. git init --bare does it, or you can set up a git server.
Gitosis-lite is easy to use and only takes a bit of time to set up. Or pay
a few bucks and use github.com or another service. This is what you will
think of as your master copy. No one ever touches it directly.

Everyone will clone the repository locally with something like

git clone git at git.yourdomain.com:yourapp.git

This will create a local copy of the repo with a remote called "origin".
Everyone works locally, commits, then pushes stuff to origin.

(make local changes)
git add .
git commit -m "fixed bug #71"   # now it's committed to my local repo
git push origin master # now it's committed to the master

other guys can
git pull origin master # now I have your changes

Git doesn't have "different copies". Everyone has the same thing, and you
use branches to figure out what your working copy looks like.

For your different users, you have to decide which branches mean what. I
follow the continuous deployment model which means that master is always in
a "ready to push" state. I usually create "topic branches" to do work and
merge them back in to master when I'm happy. Usually these topic branches
stay local, but if I want to share changes with other developers I can push
the branch itself (which is just a pointer) to the origin server and the
other devs can see what I've got.

So if I'm a developer, my procedure would be

git pull origin master # update to the latest code
git branch myfeature # change to a new feature
(implement myfeature)
git add .
git commit -m "implemented myfeature"
git checkout master # get back on to master, my changes disappear
git merge myfeature # merge the changes from myfeature onto master
git push origin master # on to the server

(it seems verbose, yes)

So for your staging and production servers, you would update master from
origin as needed (first staging, verify, then prod) in two separate clones
of the repo.

None of this requires post-commit hooks. People only log in as git to
update their local repos, never interactively.

(feel free to talk to me off list if you need more details)

Sean

I'd love some help with confirming this structure will work with git
> and maybe some tips on actual git commands to get it going.  The 2
> developers have full shell access on the production server.  I've setup
> a "git" user on it too, which both users can access if required.
>
> From what I've learned, the testing and live copies can be done with a
> special push or pull or clone, maybe with post-hooks.  I don't think
> those will be a big problem.
>
> The main stumbling block is where/what/how I make the "git master
> copy" (#5) and how I'm supposed to integrate that with the #1 & #4 dev
> copies.
>
> Thanks!!
>
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable
>



-- 
Sean Walberg <sean at ertw.com>    http://ertw.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.muug.mb.ca/pipermail/roundtable/attachments/20111102/228581c7/attachment.html>