I haven’t really talked much about my upcoming tutorial session at #phpnw12 next month before now, but I hope there’s still time to convince you to come along and learn how to use Git as your team grows in size.
That’s what I’m teaching: a strategy, plus supporting tools for Git called HubFlow, that will help you stay sane – and more importantly help you keep delivering – as your team starts to collaborate on your product.
It isn’t my strategy: the credit must go to Vincent Driessen, who first blogged about GitFlow at the start of 2010. And they aren’t my tools: again, they originally come from Vincent. All I’ve done is adapt them for working against GitHub – hence the name “HubFlow”; but if BitBucket is more to your taste (or wallet) then rest assured that both tools and strategy work can be adapted for there too.
Maybe you don’t need this strategy. If you’re working on one-off consulting gigs for clients, where you can get in quick and get out quick, then HubFlow might not be necessary. But if you’re working on any sort of product or service, either commercially or open-source, then I can strongly recommend HubFlow to you – even if you’re just at the one-man startup stage. And the benefits of adopting HubFlow only increase as your team grows in size.
I’ve already put a lot of effort into documenting HubFlow, and if you’ve previously read the docs, you might be feeling confident enough to adopt it by yourself. If you do, I think that’s awesome, and you should go for it without delay. Please do email me if I can help in any way. I’m passionate about everyone adopting the fundamentals of software engineering, and few things are more fundamental than good source control.
But if you’re still reading at this point, I hope that I can convince you to buy one of the remaining tickets for my tutorial session at #phpnw12. I don’t personally profit by it – all of us teaching at #phpnw12 are volunteers – but maybe you will.
What I’m teaching is the approach that I’ve introduced to DataSift. You might not have heard of us yet; we provide a platform for filtering social data in real time, handling terabytes of data a day at full firehose-scale, and many thousands of incoming data every second. And every piece of that data goes through code written in PHP.
Although we’re a young startup, we’ve already grown beyond 20 developers, and with that many people collaborating to build that platform, with every team working at their own pace, we needed to adopt a common way of working together with Git and GitHub so that the company continued to scale well.
- It had to be a way that allowed every developer to take full advantage of Git, especially when it comes to committing their work early and often.
- It had to allow developers to form ad-hoc teams that worked at their own pace.
- Remote working is a fact of life these days, and it had to work just as well whether everyone is in the office or working from somewhere else.
- It also had to ensure that only work that had been finished made its way into any of our releases.
- We wanted to make sure that there was an opportunity to review every change before it went into a release. Code reviews play an important part in delivering high-quality work time after time after time.
- We didn’t want pending releases to hold up new development, ever.
- And if something did screw up in production, we needed a way to go back to our last known good version, fix it, and release *that* – all without disrupting any pending releases or existing ad-hoc teams.
- Finally, it had to be easy to teach to people who are new to Git and GitHub, preferably by wrapping complicated Git operations up inside a single command each time.
Those are the benefits that HubFlow gives us. And at #phpnw12, I’ll be teaching everyone who attends my tutorial session how to get those benefits too.
What makes me qualified to teach this topic? And what makes me qualified to be teaching at all?
I’ve got 18 years of experience setting up and/or running software configuration management, taking in systems as diverse as RCS, CVS, Perforce, Continuus, Clearcase, Subversion, Mercurial, and Git. I’ve done this with, and for, organisations as small as a one-man team all the way through to large international corporates. I’ve even built a version control system for one company in the past. (Git is much better! :-) And I was around long enough to see (and learn from) the failures as well as the successes. (I’m a big believer that success teaches you a bit, but failure teaches you more). Plus, I’m the author of the HubFlow strategy, and the maintainer of the HubFlow extension for Git.
It simply isn’t possible for me to distill all of that rich and lengthy experience down into the documentation that I’ve written for HubFlow. I think the documentation is good – I wouldn’t have put my name to it otherwise – but I think you can learn even more from me in person.
I’m a qualified teacher of adults. I’m trained how to teach, and I’ve had a lot of practice doing so. My first PHP conference appearance was back in 2004 on Marco’s php|cruise, and since then I’ve spoken at the PHP NorthWest and PHP UK conferences several times. I co-wrote the Zend Certification Study Guide for PHP4. Once a year, I teach at the University of Aberystwyth, helping their Comp Sci students prepare for applying for jobs for their year in industry. Plus I’ve done a substantial amount of teaching and mentoring as part of my job and open-source work over many years. And away from computers, I’ve been teaching martial arts for over 12 years.
If you need the benefits that HubFlow brings, then I’d love to teach you in person. You can buy a ticket for my tutorial day on the #phpnw12 website. I hope to see you there.