So long svn
For the last several weeks Alan and I have been working on reeplay.it using git-svn. This is a hack that allows a developer to maintain a Git repository that commits back to an upstream Subversion repository. This gave us the most of the nifty benefits of Git without replumbing both our repository and deployment processes.
But like all hacks there are downsides. git-svn is clever but, for example, last night I had a nasty merge following by Segmentation fault and Bus error messages as git-svn dcommit was doing its work (they turned out to be problems in libsvn related to it's DAV support). That I was able to recover and continue is a testament to Git's robustness but it was just a reminder that what we were doing was basically evil.
So last night I took EY up on their very generous offer to all customers of a free Github account and following Simplistic Complexities guide migrated our Subversion repository, all 1000+ commits of it, over to Github.
I'm now sharpening up my Git knowledge by reading Scott Chacon's peecode book on Git internals, Travis Swicegood's pragprog Git beta-book, and anything else I can lay my hands on.
My outline strategy is to have a single repository with us pushing & pulling from it, rather than forking. And to have origin/staging and origin/production for deployment to respective EY environments.
My thinking behind having two branches is that it allows for a cleaner separation of what's on staging and what's on production with a specific action required to change production. It also promotes cherry-picking of changes deployed to staging (e.g. hot-fixes) without pulling across a bunch of other stuff that might be less well tested.
I'm not sure though, still feeling my way. Any advice on best practice would be welcomed.