<div class="gmail_quote">On Wed, Nov 2, 2011 at 2:23 PM, Trevor Cordes <span dir="ltr"><<a href="mailto:trevor@tecnopolis.ca">trevor@tecnopolis.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Here's the copies I currently have that I'd like to git-itize:<br>
<br>
1. Raw dev copy on my box<br>
2. Testing copy on production server<br>
3. Live copy on production server<br>4. 2nd dev copy on some other guy's server<br>5. git "master" copy somewhere on production server<br></blockquote><div><br></div><div>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 <a href="http://github.com">github.com</a> or another service. This is what you will think of as your master copy. No one ever touches it directly. </div>
<div><br></div><div>Everyone will clone the repository locally with something like</div><div><br></div><div>git clone git@git.yourdomain.com:yourapp.git</div><div><br></div><div>This will create a local copy of the repo with a remote called "origin". Everyone works locally, commits, then pushes stuff to origin.</div>
<div><br></div><div>(make local changes)</div><div>git add .</div><div>git commit -m "fixed bug #71" # now it's committed to my local repo</div><div>git push origin master # now it's committed to the master</div>
<div><br></div><div>other guys can</div><div>git pull origin master # now I have your changes</div><div><br></div><div>Git doesn't have "different copies". Everyone has the same thing, and you use branches to figure out what your working copy looks like.</div>
<div><br></div><div>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.</div>
<div><br></div><div>So if I'm a developer, my procedure would be</div><div><br></div><div>git pull origin master # update to the latest code</div><div>git branch myfeature # change to a new feature</div><div>(implement myfeature)<br>
</div><div>git add .</div><div>git commit -m "implemented myfeature"</div><div>git checkout master # get back on to master, my changes disappear</div><div>git merge myfeature # merge the changes from myfeature onto master</div>
<div>git push origin master # on to the server</div><div><br></div><div>(it seems verbose, yes)</div><div><br></div><div>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.</div>
<div><br></div><div>None of this requires post-commit hooks. People only log in as git to update their local repos, never interactively.</div><div><br></div><div>(feel free to talk to me off list if you need more details)</div>
<div> </div><div>Sean</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'd love some help with confirming this structure will work with git<br>
and maybe some tips on actual git commands to get it going. The 2<br>
developers have full shell access on the production server. I've setup<br>
a "git" user on it too, which both users can access if required.<br>
<br>