I’m not using GIT but I have to admit I’m intrigued by the hype.  It is a different paradigm which when discussed among my coworkers tends to make folks nervous.  Sorry for not helping, but I’ll be curious to know how things work out for you.

On the other hand, if anyone knows the secret to gracefully controlling 17 disparate products based loosely on a 500K LOC baseline let me know.

Haha! I'm in an organization where anything more advanced than RCS causes people to freak out. I'd love to give Git a try, but I'd need lots of ammunition to get anyone to even consider it. 

I'd love to hear anyone's experiences with Git (or Mercurial).

I've been using git exclusively for about 6 months now for all my projects.  Prior to that I was on SVN for years and then spent about a month with the git-svn bridge while I was getting my feet wet.

What kind of questions do you have about git?  Overall, I love using it and wish I had switched sooner. 

Hey Craig, thanks for responding!

Here's my current setup, pretty much I'm looking for someone to tell me what sort of workflow I should be doing. I'm a PHP developer for a public web app. I work at my company's office and from home. Occassionally, another co-worker will add some stuff to the codebase of my app, but very rarely. I've got git installed on the company webserver and my mac at home, and msysgit on my work XP machine.

Right now I pretty much just do all my coding on a flash drive, upload from there to a development area on our webserver, test, and deploy using a PHP script I wrote that just backs up the current production code and copies over the development area. Of course, sometimes I forget my flash drive at home, and I know I'll probably drop it in the ocean one of these days, so I'm looking for something a little more, uh, professional. Not to mention being able to roll back my less than inspired code experiments would be helpful.

So my questions are generally about workflow and if there's a better way to set up my environment. I have a nebulous idea about how I should be developing and committing on the local machines I'm using, and maybe pushing to the repository on the webserver, or something?! As you can see, I need a little guidance. 

Any input would be very welcome! 

Well, the good thing about git is that you really can define your own workflow.  

For something like you described I would probably do the following:

I would most likely either setup a remote "master" git repository somewhere, either on the production server of on another server that you have access to from anywhere.  For example, I have a cheap dreamhost account that I run my own git daemon on that gives me access to all my repositories from anywhere.

Then on all my local machines and other dev boxes at clients I can just very easily clone that "master" master repository and work do development on the local machines.  When I've got work and a bunch of commits that are only on my local boxes that I want to push to other machines I just simply do a git push back to that "master" repository that that I can then do a "git pull" on any of those other machines and keep them in sync.

This is more or less the method that the linux kernel team uses for their kernel development (of course, on a much larger scale and with several intermediate "master repos" layers).

A key feature of git is that, of course, you arent' required to have any kind of "master/central" repository and you could truly push and pull to each and every local dev machine directly if you wanted, but I have found that to be a bit more trouble than its worth for small projects, especially when there is a small dev team (1-10 devs).

You could truly run your production site off of this master repository, but my guess is that you probably don't want to just for safety reasons.  I would most likely continue to use your already existing PHP deployment scripts and just have them run off of the git repository instead of the flash drive or wherever you upload to now.

If I were doing it, I would install git on the production machine and clone the "master" repsitory directly into the webroot.  Then in my deploy scripts I could just simply issue a git pull (or git fetch/merge) command and have it update itself to the latest stable code from the repos.  Then you would also have the built-in functionality to be able to issue code rollbacks if you found errors that were show-stoppers in production.  Your script could just run a git checkout OLD_COMMIT_VERSION on the production server to grab a past checkin that you knew was good.  

Git tags would be a good thing to use in this case.  I would tag each commit that I was pushing to production so I could easily track what commits were pushed to the server and I could issue rollbacks on those specific tags instead of hunting for a specific commit SHA.

Hope that helped a bit. 

Wow, awesome stuff. That's exactly the kind of thing I was looking for. And though you lost me a bit at the end, it's certainly pointed me in the direction of what else I need to learn.

Thank you so much for sharing all that! I'll try to update this thread when I get set up.