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.
My outline strategy is to have a single repository with us pushing & pulling from it, rather than forking. And to have
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.